https://llvm.org/bugs/show_bug.cgi?id=26943
Bug ID: 26943
Summary: InstCombine: frem X, (C ? 0 : Y) -> frem X, Y changes
result
Product: libraries
Version: trunk
Hardware: PC
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Classification: Unclassified
The following program:
$ cat ../example.ll
define i1 @main() {
%w = call float @foo(i1 1, float 17.0)
%w2 = frem float 17.0, 42.0
%rr = fcmp oeq float %w, %w2
ret i1 %rr
}
define float @foo(i1 %c, float %x) {
%r = select i1 %c, float 0.0, float 42.0
%rr = frem float %x, %r
ret float %rr
}
gets optimized to:
$ bin/opt < ../example.ll -instcombine -S > ../example2.ll && cat
../example2.ll
; ModuleID = '<stdin>'
define i1 @main() {
%w = call float @foo(i1 true, float 1.700000e+01)
%rr = fcmp oeq float %w, 1.700000e+01
ret i1 %rr
}
define float @foo(i1 %c, float %x) {
%rr = frem float %x, 4.200000e+01
ret float %rr
}
The output of the original program and the optimized program is not the same:
$ bin/lli ../example.ll; echo $?
0
$ bin/lli ../example2.ll; echo $?
1
It seems like the optimization assumes that a frem %x, 0.0 results in undefined
behavior but according to [0], the result should just be NaN and an error flag
should be set. My understanding is that frem corresponds to C's fmod (see e.g.
[1]), so it seems like the optimization is invalid.
[0] http://pubs.opengroup.org/onlinepubs/9699919799/functions/fmod.html
[1]
http://llvm.org/docs/doxygen/html/classllvm_1_1APFloat.html#ab715d4ba706dd8dd1c7d51e43d067d4c
--
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
