[LLVMbugs] [Bug 12172] New: Incorrect sign extension of i1 to i32 in vectors

[bugzilla-daemon at llvm.org]

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

             Bug #: 12172
           Summary: Incorrect sign extension of i1 to i32 in vectors
           Product: libraries
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PowerPC
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: benh at kernel.crashing.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 8137
  --> http://llvm.org/bugs/attachment.cgi?id=8137
Test program

While trying to get llvmpipe to work on ppc, I found that all the
mask generation logic was busted as vectors of i1's
(obtained from compare opts of two vectors) were not properly sign
extended to vectors of i32's. This is without attempt at using
altivec (yet), ie, plain fp code appears to be playing games with
the condition register effectively zero-extending instead.

The attached test case shows this. It's more complex than I would
have liked because my attempts at simplifying it hit bug #12171.

(It looks like a simple sign extension of a non-vector i1 to i32 works)

The program will run some trivial compares (float ULT compare against
the constant 2.0) for different values, sign extend the resulting
vector and and display the first element.

The output on i386 (expected result) is :

Value 1.000000 result ffffffff
Value 2.000000 result 0
Value 2.000100 result 0
Value 3.000000 result 0
Value -1.000000 result ffffffff

The output on powerpc (32-bit, triplet is powerpc-linux-gnu) is:

Value 1.000000 result 1
Value 2.000000 result 0
Value 2.000100 result 0
Value 3.000000 result 0
Value -1.000000 result 1

I get the same results whether I just run it through lli, or llc it
and then link & run it.

Note: To test on i386, remove the triplet specification. It's there
because for some reason, trunk appears to pickup a 64-bit default
even inside a 32-bit lli or app, which doesn't quite work :-) I may
have done something wrong, not sure how it picks the default.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.