[llvm-bugs] [Bug 26958] New: InstCombine: fadd (fsub nnan ninf 0.0, X), X => 0 incorrect for X = NaN

[via llvm-bugs]

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

            Bug ID: 26958
           Summary: InstCombine: fadd (fsub nnan ninf 0.0, X), X => 0
                    incorrect for X = NaN
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: andres.noetzli at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

InstCombine optimizes the following program:

$ cat ../example.ll
define float @test(float %x) {
  %a = fsub nnan ninf float 0.0, %x
  %r = fadd float %a, %x
  ret float %r
}

To the constant 0.0:

$ bin/opt < ../example.ll -instcombine -S
; ModuleID = '<stdin>'

define float @test(float %x) {
  ret float 0.000000e+00
}

This does not seem to be correct, however, because the language reference
states that:

"nnan: No NaNs - Allow optimizations to assume the arguments and result are not
NaN. Such optimizations are required to retain defined behavior over NaNs, but
the value of the result is undefined." [0]

Using this rule we can construct a counterexample. Let "%x = NaN", then "%a =
undef" and "%r = fadd undef, NaN", so we cannot get 0.0 for %r because no
matter what we choose for undef, we always end up with %r being NaN.

This behavior is implemented in SimplifyFAddInst() in InstructionSimplify. The
optimization just checks whether nnan and ninf appear at least once somewhere
on the fadd and the fsub instruction but as the example above indicates, this
condition seems too weak.

[0] http://llvm.org/docs/LangRef.html#fast-math-flags

-- 
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/20160316/087b0ab5/attachment.html>