Special-case transmute for primitive, SIMD & pointer types.

[huonw]

This detects (a subset of) the cases when transmute::<T, U>(x) can be
lowered to a direct bitcast T x to U in LLVM. This assists with
efficiently handling a SIMD vector as multiple different types,
e.g. swapping bytes/words/double words around inside some larger vector
type.

C compilers like GCC and Clang handle integer vector types as __m128i
for all widths, and implicitly insert bitcasts as required. This patch
allows Rust to express this, even if it takes a bit of unsafe, whereas
previously it was impossible to do at all without inline assembly.

Example:

pub fn reverse_u32s(u: u64x2) -> u64x2 {
    unsafe {
        let tmp = mem::transmute::<_, u32x4>(u);
        let swapped = u32x4(tmp.3, tmp.2, tmp.1, tmp.0);
        mem::transmute::<_, u64x2>(swapped)
    }
}

Compiling with --opt-level=3 gives:

Before

define <2 x i64> @_ZN12reverse_u32s20hbdb206aba18a03d8tbaE(<2 x i64>) unnamed_addr #0 {
entry-block:
  %1 = bitcast <2 x i64> %0 to i128
  %u.0.extract.trunc = trunc i128 %1 to i32
  %u.4.extract.shift = lshr i128 %1, 32
  %u.4.extract.trunc = trunc i128 %u.4.extract.shift to i32
  %u.8.extract.shift = lshr i128 %1, 64
  %u.8.extract.trunc = trunc i128 %u.8.extract.shift to i32
  %u.12.extract.shift = lshr i128 %1, 96
  %u.12.extract.trunc = trunc i128 %u.12.extract.shift to i32
  %2 = insertelement <4 x i32> undef, i32 %u.12.extract.trunc, i64 0
  %3 = insertelement <4 x i32> %2, i32 %u.8.extract.trunc, i64 1
  %4 = insertelement <4 x i32> %3, i32 %u.4.extract.trunc, i64 2
  %5 = insertelement <4 x i32> %4, i32 %u.0.extract.trunc, i64 3
  %6 = bitcast <4 x i32> %5 to <2 x i64>
  ret <2 x i64> %6
}

_ZN12reverse_u32s20hbdb206aba18a03d8tbaE:
    .cfi_startproc
    movd    %xmm0, %rax
    punpckhqdq  %xmm0, %xmm0
    movd    %xmm0, %rcx
    movq    %rcx, %rdx
    shrq    $32, %rdx
    movq    %rax, %rsi
    shrq    $32, %rsi
    movd    %eax, %xmm0
    movd    %ecx, %xmm1
    punpckldq   %xmm0, %xmm1
    movd    %esi, %xmm2
    movd    %edx, %xmm0
    punpckldq   %xmm2, %xmm0
    punpckldq   %xmm1, %xmm0
    retq

After

define <2 x i64> @_ZN12reverse_u32s20hbdb206aba18a03d8tbaE(<2 x i64>) unnamed_addr #0 {
entry-block:
  %1 = bitcast <2 x i64> %0 to <4 x i32>
  %2 = shufflevector <4 x i32> %1, <4 x i32> undef, <4 x i32> <i32 3, i32 2, i32 1, i32 0>
  %3 = bitcast <4 x i32> %2 to <2 x i64>
  ret <2 x i64> %3
}

_ZN12reverse_u32s20hbdb206aba18a03d8tbaE:
    .cfi_startproc
    pshufd  $27, %xmm0, %xmm0
    retq

[Ms2ger]

"lose", not "loose"

[huonw]

Whoops, thanks.

[huonw]

Grieverheart/dsfmt-rs#2 is a real-world example of something this helps.

[eddyb]

Equivalent to let datum = unpack_datum!(bcx, expr::trans(bcx, &*arg_exprs[0]));.

[huonw]

Fixed.

[eddyb]

What does this do for transmute::<(), ()>(())? I know it's not a real world usecase, but () is currently classified as a scalar and its LLVM type is {} which I suspect is not valid for a bitcast.

IMO the use of type_is_scalar is ad-hoc and fragile, could we not use the LLVM type instead?
I'm thinking integers, floating-point and vectors ought to be enough for now.

This way we could also (easily) handle pointer -> pointer and pointer -> integer / integer -> pointer casts, even when the Rust type doesn't readily provide this information (trans::adt could very well flatten an enum+newtype hierarchy many levels deep into a single pointer).

[nikomatsakis]

I think in principle this makes sense. @eddyb is probably right that examining the LLVM types may be a good idea.

[huonw]

Updated to look at the LLVM type. This also now includes detecting the pointer -> pointer case for bitcast.

[eddyb]

I expect this to work fine for types that implement Drop if datum.to_llscalarish() is replaced with something like if datum.kind.is_by_ref() { load_ty(bcx, datum.val, datum.ty) } else { datum.val }.

[huonw]

Making this change:

--- a/src/librustc_trans/trans/intrinsic.rs
+++ b/src/librustc_trans/trans/intrinsic.rs
@@ -192,11 +192,8 @@ pub fn trans_intrinsic_call<'a, 'blk, 'tcx>(mut bcx: Block<'blk, 'tcx>,
                     (nonpointer_nonaggregate(in_kind) && nonpointer_nonaggregate(ret_kind)) || {
                         in_kind == TypeKind::Pointer && ret_kind == TypeKind::Pointer
                     };
-                let primitive =
-                    !ty::type_needs_drop(ccx.tcx(), in_type) &&
-                    !ty::type_needs_drop(ccx.tcx(), ret_ty.unwrap());

-                let dest = if bitcast_compatible && primitive {
+                let dest = if bitcast_compatible {
                     // if we're here, the type is scalar-like (a primitive or a
                     // SIMD type), and so can be handled as a by-value ValueRef
                     // and can also be directly bitcast to the target type.
@@ -205,7 +202,11 @@ pub fn trans_intrinsic_call<'a, 'blk, 'tcx>(mut bcx: Block<'blk, 'tcx>,
                     // are done efficiently implicitly in C with the `__m128i`
                     // type and so this means Rust doesn't lose out there).
                     let datum = unpack_datum!(bcx, expr::trans(bcx, &*arg_exprs[0]));
-                    let val = datum.to_llscalarish(bcx);
+                    let val = if datum.kind.is_by_ref() {
+                        load_ty(bcx, datum.val, datum.ty)
+                    } else {
+                        datum.val
+                    };
                     let cast_val = BitCast(bcx, val, llret_ty);

                     match dest {

gives me aborts compiling stage2 core (i.e. the stage1 compiler is codegened incorrectly):

rustc: x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore

You've met with a terrible fate, haven't you?

fatal runtime error:  assertion failed: self.state != Armed

I assume, if it exists, destructor of the input (i.e. datum.val) needs to be cancelled, but I do not know how to do this. Handling destructors correctly would seem to be significantly more error prone, which may not be what we want for this minor tweak mainly designed to allow slightly better handling of SIMD types.

[alexcrichton]

Looks like bors stalled out on this PR, but it passed all platforms but the one slave that was lost, so I have merged this manually.