[llvm-bugs] [Bug 25543] New: [x86] bad codegen while extracting vector elements

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=25543

            Bug ID: 25543
           Summary: [x86] bad codegen while extracting vector elements
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: spatel+llvm at rotateright.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

It may be possible to further reduce this, but here's a small C example that
shows the problem(s):

$ cat shifty.c
#include <immintrin.h>

void foo(__m128i v, int bits, short *s0, short *s1) {
  int i[4];
  _mm_storeu_si128((__m128i *)i, v); // get vector bits as ints
  if (bits & 1) { *s0 = i[0]; }      // conditionally store part of elt 0
  if (bits & 2) { *s1 = i[1]; }      // conditionally store part of elt 1
}

Testing with:
$ ./clang -v
clang version 3.8.0 (trunk 253043)
Target: x86_64-apple-darwin15.0.0


$ ./clang -fomit-frame-pointer -O2 shifty.c -S -o -
_foo:
    movd    %xmm0, %rax   # Wrong disasm? That's a 64-bit move (movq).
    testb    $1, %dil
    je    LBB0_2
    movw    %ax, (%rsi)
LBB0_2:
    testb    $2, %dil
    je    LBB0_4

# Things get weird...why are we messing with elements 2 and 3?

    pshufd    $78, %xmm0, %xmm0       ## xmm0 = xmm0[2,3,0,1]
    movd    %xmm0, %rcx
    shldq    $32, %rax, %rcx   # Could have just shifted %rax left?
    movw    %cx, (%rdx)
LBB0_4:
    retq

-- 
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/20151116/bf2f807a/attachment.html>