[LLVMbugs] [Bug 15309] New: vector uitofp fails for 64-bit integers

[bugzilla-daemon at llvm.org]

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

            Bug ID: 15309
           Summary: vector uitofp fails for 64-bit integers
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: babslachem at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Let's consider following code to convert a 2 x i64 vector into a 2 x float
vector:


; ModuleID = 'opencl-kernel-2N45Jj-2-src-def.ll'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32"
target triple = "i386-pc-linux-gnu"

define void @test_convert_float2_ulong2(<2 x i64>* nocapture %src, <2 x float>*
nocapture %dest) noinline {
L.entry:
  %0 = getelementptr <2 x i64>* %src, i32 10
  %1 = load <2 x i64>* %0, align 16
  %2 = uitofp <2 x i64> %1 to <2 x float>
  %3 = getelementptr <2 x float>* %dest, i32 10
  store <2 x float> %2, <2 x float>* %3, align 8
  ret void
}


Using llc as follows:

llc -march=x86 uitofp.ll -o uitofp.s


We got following assembly generated:

    .file    "uitofp.ll"
    .section    .rodata.cst16,"aM", at progbits,16
    .align    16
.LCPI0_0:
    .quad    4841369599423283200     # double 4.503600e+15
    .quad    4841369599423283200     # double 4.503600e+15
    .text
    .globl    test_convert_float2_ulong2
    .align    16, 0x90
    .type    test_convert_float2_ulong2, at function
test_convert_float2_ulong2:             # @test_convert_float2_ulong2
    .cfi_startproc
# BB#0:                                 # %L.entry
    movl    4(%esp), %eax
    movapd    .LCPI0_0, %xmm0
    movapd    160(%eax), %xmm1
    orpd    %xmm0, %xmm1
    subpd    %xmm0, %xmm1
    cvtpd2ps    %xmm1, %xmm0
    movl    8(%esp), %eax
    extractps    $1, %xmm0, 84(%eax)
    movss    %xmm0, 80(%eax)
    ret
.Ltmp0:
    .size    test_convert_float2_ulong2, .Ltmp0-test_convert_float2_ulong2
    .cfi_endproc


    .section    ".note.GNU-stack","", at progbits

If for instance we want to convert vector <0x0010000000000000,
0x0010000000000000> expected result is: <0x59800000, 0x59800000>.
With implemented algorithm we got:

orpd    %xmm0, %xmm1 => xmm1 = <0x4330000000000000, 0x4330000000000000> |
<0x0010000000000000, 0x0010000000000000> = <0x4330000000000000,
0x4330000000000000>
subpd    %xmm0, %xmm1 => xmm1 - xmm0 = <0x0000000000000000, 0x0000000000000000>

Thus final results is <0x00000000, 0x00000000> instead of  <0x59800000,
0x59800000>.

-- 
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/20130220/b3d6d509/attachment.html>