[llvm-bugs] [Bug 31296] New: Incorrect shuffles produced with XOP

[via llvm-bugs]

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

            Bug ID: 31296
           Summary: Incorrect shuffles produced with XOP
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: sroland at vmware.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

With XOP enabled, the code produced by llvm for some shuffles is wrong.

This function

define void at fetch_r32_float_float(<4 x float>* %out, i8* %in) {
entry:
  %0 = getelementptr i8, i8* %in, i32 0
  %1 = bitcast i8* %0 to i32*
  %2 = load i32, i32* %1
  %3 = zext i32 %2 to i128
  %4 = bitcast i128 %3 to <4 x float>
  %5 = shufflevector <4 x float> %4, <4 x float> <float 0.000000e+00, float
1.000000e+00, float undef, float undef>, <4 x i32> <i32 0, i32 4, i32 4, i32 5>
  store <4 x float> %5, <4 x float>* %out
  ret void
}

with -mattr=+xop produces:

fetch_r32_float_float:                  # @fetch_r32_float_float
        .cfi_startproc
# BB#0:                                 # %entry
        vpermilps       $65, .LCPI0_0(%rip), %xmm0 # xmm0 = mem[1,0,0,1]
        vmovaps %xmm0, (%rdi)
        retq

Which is very obviously wrong (the load got optimized away and the
corresponding element in the shuffled vector replaced with just a constant from
the second vector).

(This is basically a testcase from mesa lp_test_format, we recently enabled xop
feature or more accurately we enabled all features the cpu has support for
which uncovered this bug.)
This does not happen with avx2 or other instruction sets as far as I can tell,
it's specific to XOP.

-- 
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/20161206/2109245f/attachment-0001.html>