diff options
author | Junyan He <junyan.he@linux.intel.com> | 2015-03-17 18:08:40 +0800 |
---|---|---|
committer | Zhigang Gong <zhigang.gong@intel.com> | 2015-03-18 16:22:13 +0800 |
commit | af0266b904973eddbacd3462bad78dab13fb7e4e (patch) | |
tree | 3299fee1bc87c59b1cd6dc226e1f6ab425c60960 /backend/src/ir | |
parent | de8168dbae83c609ff4c12c1ab990109896c4434 (diff) |
Generate NAN for UNDEF value in printf parser.stable
llvm 3.6 will give a UNDEF value for NAN. The will cause
the store instruction for UNDEF to be ignored. We need
to modify it to NAN here.
Comments from Zhigang:
"
The related commit of why LLVM won't just simply return NaN for such
case is at:
Make the sqrt intrinsic return undef for a negative input.
As discussed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140609/220598.html
And again here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-September/077168.html
The sqrt of a negative number when using the llvm intrinsic is undefined.
We should return undef rather than 0.0 to match the definition in the LLVM IR lang ref.
This change should not affect any code that isn't using "no-nans-fp-math";
ie, no-nans is a requirement for generating the llvm intrinsic in place of a sqrt function call.
Unfortunately, the behavior introduced by this patch will not match current gcc, xlc, icc, and
possibly other compilers. The current clang/llvm behavior of returning 0.0 doesn't either.
We knowingly approve of this difference with the other compilers in an attempt to flag code
that is invoking undefined behavior.
A front-end warning should also try to convince the user that the program will fail:
http://llvm.org/bugs/show_bug.cgi?id=21093
Differential Revision: http://reviews.llvm.org/D5527
This patch is a workaround for the following scenario:
printf("%f \n", sqrt(-1.0f));
"
Signed-off-by: Junyan He <junyan.he@linux.intel.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Diffstat (limited to 'backend/src/ir')
0 files changed, 0 insertions, 0 deletions