[LLVMbugs] [Bug 15215] New: Bitcast of <4 x i1> to i4 gives unexpected result

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=15215

            Bug ID: 15215
           Summary: Bitcast of <4 x i1> to i4 gives unexpected result
           Product: new-bugs
           Version: 3.2
          Hardware: Other
                OS: other
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: kai.trojahner at rtt.ag
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 9985
  --> http://llvm.org/bugs/attachment.cgi?id=9985&action=edit
Demonstrator

On x86, the following two LLVM IR functions give different results.

define i32 @bad(<4 x i32> %input) {
entry:
  %0 = trunc <4 x i32> %input to <4 x i1>
  %1 = bitcast <4 x i1> %0 to i4
  %2 = zext i4 %1 to i32
  ret i32 %2
}

define i32 @good(<4 x i32> %input) {
entry:
  %0 = trunc <4 x i32> %input to <4 x i1>
  %1 = extractelement <4 x i1> %0, i32 0
  %e1 = select i1 %1, i32 1, i32 0
  %2 = extractelement <4 x i1> %0, i32 1
  %e2 = select i1 %2, i32 2, i32 0
  %3 = extractelement <4 x i1> %0, i32 2
  %e3 = select i1 %3, i32 4, i32 0
  %4 = extractelement <4 x i1> %0, i32 3
  %e4 = select i1 %4, i32 8, i32 0
  %5 = or i32 %e1, %e2
  %6 = or i32 %5, %e3
  %7 = or i32 %6, %e4
  ret i32 %7
}

A demonstrator program illustrates the effect:

#include <emmintrin.h>
#include <stdio.h>

extern int bad(__m128i input);
extern int good(__m128i input);

int main() {
  int i;
  __m128i input[16];

  input[0] = _mm_set_epi32(0, 0, 0, 0);
  input[1] = _mm_set_epi32(0, 0, 0, -1);
  input[2] = _mm_set_epi32(0, 0, -1, 0);
  input[3] = _mm_set_epi32(0, 0, -1, -1);
  input[4] = _mm_set_epi32(0, -1, 0, 0);
  input[5] = _mm_set_epi32(0, -1, 0, -1);
  input[6] = _mm_set_epi32(0, -1, -1, 0);
  input[7] = _mm_set_epi32(0, -1, -1, -1);
  input[8] = _mm_set_epi32(-1, 0, 0, 0);
  input[9] = _mm_set_epi32(-1, 0, 0, -1);
  input[10]= _mm_set_epi32(-1, 0, -1, 0);
  input[11]= _mm_set_epi32(-1, 0, -1, -1);
  input[12]= _mm_set_epi32(-1, -1, 0, 0);
  input[13]= _mm_set_epi32(-1, -1, 0, -1);
  input[14]= _mm_set_epi32(-1, -1, -1, 0);
  input[15]= _mm_set_epi32(-1, -1, -1, -1);

  for (i=0; i<16; i++) {
    printf("permutation %i, good: %x: bad: %x\n",
           i, good(input[i]), bad(input[i]));
  }
  return 0;
}

On my machine (Xeon 5160, SSE2, Windows 7, Cygwin, demonstrator compiled with
MSVC), the program yields:

permutation 0, good: 0: bad: 0
permutation 1, good: 1: bad: 0
permutation 2, good: 2: bad: 1
permutation 3, good: 3: bad: 1
permutation 4, good: 4: bad: 0
permutation 5, good: 5: bad: 0
permutation 6, good: 6: bad: 1
permutation 7, good: 7: bad: 1
permutation 8, good: 8: bad: 0
permutation 9, good: 9: bad: 0
permutation 10, good: a: bad: 1
permutation 11, good: b: bad: 1
permutation 12, good: c: bad: 0
permutation 13, good: d: bad: 0
permutation 14, good: e: bad: 1
permutation 15, good: f: bad: 1

Even more bizarrely, on a different machine (Xeon W3565, SSE4.1, Linux,
demonstrator compiled with GCC), the program yields:

permutation 0, good: 0: bad: 0
permutation 1, good: 1: bad: 1
permutation 2, good: 2: bad: 0
permutation 3, good: 3: bad: 1
permutation 4, good: 4: bad: 0
permutation 5, good: 5: bad: 1
permutation 6, good: 6: bad: 0
permutation 7, good: 7: bad: 1
permutation 8, good: 8: bad: 0
permutation 9, good: 9: bad: 1
permutation 10, good: a: bad: 0
permutation 11, good: b: bad: 1
permutation 12, good: c: bad: 0
permutation 13, good: d: bad: 1
permutation 14, good: e: bad: 0
permutation 15, good: f: bad: 1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130208/a22265ef/attachment.html>