[llvm-bugs] [Bug 36600] New: Patterns for fabs from select in DAGCombiner are folded without regard for sign of zero
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Mar 5 08:51:21 PST 2018
https://bugs.llvm.org/show_bug.cgi?id=36600
Bug ID: 36600
Summary: Patterns for fabs from select in DAGCombiner are
folded without regard for sign of zero
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedbugs at nondot.org
Reporter: mikhail.dvoretckii at intel.com
CC: llvm-bugs at lists.llvm.org
The test case:
-bash-4.2$ cat fabszero.cpp
#include <stdio.h>
int main(int argc, char **argv)
{
double zero;
sscanf(argv[1], "%lf", &zero);
zero = (zero <= 0) ? (-0.0 - zero) : zero;
printf("%f\n", zero);
return 0;
}
-bash-4.2$
If compiled with strict FP math, this test case returns -0.0 for the 0.0 input.
-bash-4.2$ clang -O3 fabszero.cpp
-bash-4.2$ ./a.out 0.0
-0.000000
-bash-4.2$
If compiled with a no-NaNs flag, even without the no-signed-zeros flag, the
code is folded into fabs, producing non-negative outputs for all inputs.
-bash-4.2$ clang -O3 -Xclang -menable-no-nans fabszero.cpp
-bash-4.2$ ./a.out 0.0
0.000000
-bash-4.2$
The cause of this is the patterns folded into fabs in SimplifySelectCC is
DAGCombiner.cpp, specifically
select (setg[te] X, +/-0.0), X, fneg(X) -> fabs
select (setl[te] X, +/-0.0), fneg(X), X -> fabs
Since 0.0 and -0.0 evaluate as equal and lead to the same option being
selected, all of these patterns should produce -0.0 on one of the zero inputs
which contradicts fabs semantics. This folding thus changes sign-of-zero
behavior without checking the appropriate flag.
--
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/20180305/e4a6341c/attachment.html>
More information about the llvm-bugs
mailing list