[LLVMbugs] [Bug 20556] New: fast vector fneg not optimized like fast scalar fneg

[bugzilla-daemon at llvm.org]

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

            Bug ID: 20556
           Summary: fast vector fneg not optimized like fast scalar fneg
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: spatel+llvm at rotateright.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This is a test for optimizing the "wrong" definition of fneg (one that uses
+0.0 rather than -0.0) when enable-unsafe-fp-math is used.

Using llc built from r214897 on x86-64:

$ cat fast_fneg.ll
define float @fneg(float %x) #0 {
entry:
  %sub = fsub float 0.000000e+00, %x
  ret float %sub
}

define <4 x float> @fneg4(<4 x float> %x) #0 {
entry:
  %sub = fsub <4 x float> zeroinitializer, %x
  ret <4 x float> %sub
}


$ ./llc -enable-unsafe-fp-math fast_fneg.ll -o -
    .section    __TEXT,__text,regular,pure_instructions
    .macosx_version_min 13, 3
    .section    __TEXT,__literal16,16byte_literals
    .align    4
LCPI0_0:
    .long    2147483648              ## float -0.000000e+00
    .long    2147483648              ## float -0.000000e+00
    .long    2147483648              ## float -0.000000e+00
    .long    2147483648              ## float -0.000000e+00
    .section    __TEXT,__text,regular,pure_instructions
    .globl    _fneg
    .align    4, 0x90
_fneg:                                  ## @fneg
    .cfi_startproc
## BB#0:                                ## %entry
    xorps    LCPI0_0(%rip), %xmm0
    retq
    .cfi_endproc

    .globl    _fneg4
    .align    4, 0x90
_fneg4:                                 ## @fneg4
    .cfi_startproc
## BB#0:                                ## %entry
    xorps    %xmm1, %xmm1
    subps    %xmm0, %xmm1
    movaps    %xmm1, %xmm0
    retq
    .cfi_endproc


-------------------------------------

We optimized the scalar case to load a constant 0x80000000 to flip the sign bit
and avoid a subtraction. Shouldn't we do the same thing for the vector case?

-- 
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/20140805/4bf827b1/attachment.html>