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: [email protected]
Reporter: [email protected]
CC: [email protected]
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.
_______________________________________________
llvm-bugs mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
