Failure in run-pass/simd/simd-intrinsic-generic-select on Big-Endian Targets

[smaeul]

This was found while building rustc 1.33.0 on powerpc64-unknown-linux-musl. Test run-pass/simd/simd-intrinsic-generic-select fails at the third simd_select_bitmask test:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `u32x8(8, 1, 10, 3, 12, 5, 14, 7)`,
 right: `u32x8(0, 9, 2, 11, 4, 13, 6, 15)`', src/test/run-pass/simd/simd-intrinsic-generic-select.rs:159:9

The LLVM IR generated for this test case on x86_64-unknown-linux-musl and powerpc64-unknown-linux-musl (respectively) is identical:

  %1036 = load <8 x i32>, <8 x i32>* %a83, align 32
  %1037 = load <8 x i32>, <8 x i32>* %b84, align 32
  %1038 = select <8 x i1> bitcast (<1 x i8> <i8 -16> to <8 x i1>), <8 x i32> %1036, <8 x i32> %1037
  store <8 x i32> %1038, <8 x i32>* %r101, align 32

  %1036 = load <8 x i32>, <8 x i32>* %a83, align 32
  %1037 = load <8 x i32>, <8 x i32>* %b84, align 32
  %1038 = select <8 x i1> bitcast (<1 x i8> <i8 -16> to <8 x i1>), <8 x i32> %1036, <8 x i32> %1037
  store <8 x i32> %1038, <8 x i32>* %r101, align 32

The test appears to expect that the bitmask is interpreted as bitwise little-endian (in other words, the LSB selects the first element from the vectors). However, the implementation uses a bitcast to a vector of i1. On big-endian architectures such as powerpc64, the LSB becomes the last element of this i1 vector, not the first.

Unfortunately, all of the upstream test cases are symmetrical, so "choosing the wrong vector" and "reading the bitmask backwards" are indistinguishable. I added an additional test case:

        let r: u32x8 = simd_select_bitmask(0b11110101u8, a, b);
        let e = u32x8(0, 9, 2, 11, 4, 5, 6, 7);
        assert_eq!(r, e);

This passes on x86_64-unknown-linux-musl, but fails on powerpc64-unknown-linux-musl with:

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `u32x8(0, 1, 2, 3, 12, 5, 14, 7)`,
 right: `u32x8(0, 9, 2, 11, 4, 5, 6, 7)`', src/test/run-pass/simd/simd-intrinsic-generic-select.rs:50:9

The two "unlike" elements were chosen from the wrong place in the vector.

Since the vectors are 256 bits, and the POWER VSX registers are only 128 bits wide, LLVM must split each vector across two registers. The following powerpc64 assembly is from the last test case (0b11110000u8), and clearly shows that LLVM (not the hardware) picks the first half of a and the second half of b:

   0x000000000000416c <+36>:    li      r3,0                                                                                                                                                   

36          unsafe {
37              let a = u32x8(0, 1, 2, 3, 4, 5, 6, 7);
   0x0000000000004170 <+40>:    stw     r3,288(r1)                                                                                                                                             
   0x0000000000004174 <+44>:    li      r3,1                                                                                                                                                   
   0x0000000000004178 <+48>:    stw     r3,292(r1)
   0x000000000000417c <+52>:    li      r3,2
   0x0000000000004180 <+56>:    stw     r3,296(r1)
   0x0000000000004184 <+60>:    li      r3,3
   0x0000000000004188 <+64>:    stw     r3,300(r1)
   0x000000000000418c <+68>:    li      r3,4
   0x0000000000004190 <+72>:    stw     r3,304(r1)                                                                                                                                             
   0x0000000000004194 <+76>:    li      r3,5
   0x0000000000004198 <+80>:    stw     r3,308(r1)
   0x000000000000419c <+84>:    li      r3,6
   0x00000000000041a0 <+88>:    stw     r3,312(r1)
   0x00000000000041a4 <+92>:    li      r3,7                                                                                                                                                   
   0x00000000000041a8 <+96>:    stw     r3,316(r1)                                                                                                                                             
   0x00000000000041ac <+100>:   li      r3,8

38              let b = u32x8(8, 9, 10, 11, 12, 13, 14, 15);
   0x00000000000041b0 <+104>:   stw     r3,320(r1)
   0x00000000000041b4 <+108>:   li      r3,9
   0x00000000000041b8 <+112>:   stw     r3,324(r1)                                                                                                                                             
   0x00000000000041bc <+116>:   li      r3,10
   0x00000000000041c0 <+120>:   stw     r3,328(r1)                                                                                                                                             
   0x00000000000041c4 <+124>:   li      r3,11
   0x00000000000041c8 <+128>:   stw     r3,332(r1)
   0x00000000000041cc <+132>:   addi    r3,r1,336
   0x00000000000041d0 <+136>:   li      r4,12
   0x00000000000041d4 <+140>:   stw     r4,336(r1)
   0x00000000000041d8 <+144>:   li      r4,13                                                                                                                                                  
   0x00000000000041dc <+148>:   stw     r4,340(r1)
   0x00000000000041e0 <+152>:   li      r4,14
   0x00000000000041e4 <+156>:   stw     r4,344(r1)
   0x00000000000041e8 <+160>:   li      r4,15
   0x00000000000041ec <+164>:   stw     r4,348(r1)
...
60              let r: u32x8 = simd_select_bitmask(0b11110000u8, a, b);
   0x00000000000048cc <+1924>:  addi    r3,r1,288
   0x00000000000048d0 <+1928>:  lvx     v2,0,r3
   0x00000000000048d4 <+1932>:  addi    r3,r1,336
   0x00000000000048d8 <+1936>:  lvx     v3,0,r3
   0x00000000000048dc <+1940>:  addi    r3,r1,1488
   0x00000000000048e0 <+1944>:  stvx    v3,0,r3
   0x00000000000048e4 <+1948>:  addi    r3,r1,1472
   0x00000000000048e8 <+1952>:  stvx    v2,0,r3

So is this a bug in the test, because it should be ensuring that the bitmask is in native vector/endian order? Or in the implementation of simd_select_bitmask, because it should always take a little-endian bitmask and reverse the bits as necessary?

[smaeul]

From rust-lang/stdarch#310 (comment) it looks like that the bitcast is the intended semantics, so that would mean the test is invalid on big-endian targets.

Thoughts, @gnzlbg @alexcrichton ?

[gnzlbg]

So is this a bug in the test, because it should be ensuring that the bitmask is in native vector/endian order?

This, we should only enable the test for little endian platforms, maybe adding a new test for big endian platforms.