summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/APFloat.cpp
diff options
context:
space:
mode:
authorHal Finkel <hfinkel@anl.gov>2014-10-14 19:23:07 +0000
committerHal Finkel <hfinkel@anl.gov>2014-10-14 19:23:07 +0000
commit171c2ec0087165fb28b1d9221392fd5473dd110e (patch)
tree00dc903857b43c47c0ad202d1199da87a6abfd2a /llvm/lib/Support/APFloat.cpp
parentdb3f0a24ec7b97185dda68558effbd01c4f1e621 (diff)
downloadbcm5719-llvm-171c2ec0087165fb28b1d9221392fd5473dd110e.tar.gz
bcm5719-llvm-171c2ec0087165fb28b1d9221392fd5473dd110e.zip
Revert "r216914 - Revert: [APFloat] Fixed a bug in method 'fusedMultiplyAdd'"
Reapply r216913, a fix for PR20832 by Andrea Di Biagio. The commit was reverted because of buildbot failures, and credit goes to Ulrich Weigand for isolating the underlying issue (which can be confirmed by Valgrind, which does helpfully light up like the fourth of July). Uli explained the problem with the original patch as: It seems the problem is calling multiplySignificand with an addend of category fcZero; that is not expected by this routine. Note that for fcZero, the significand parts are simply uninitialized, but the code in (or rather, called from) multiplySignificand will unconditionally access them -- in effect using uninitialized contents. This version avoids using a category == fcZero addend within multiplySignificand, which avoids this problem (the Valgrind output is also now clean). Original commit message: [APFloat] Fixed a bug in method 'fusedMultiplyAdd'. When folding a fused multiply-add builtin call, make sure that we propagate the correct result in the case where the addend is zero, and the two other operands are finite non-zero. Example: define double @test() { %1 = call double @llvm.fma.f64(double 7.0, double 8.0, double 0.0) ret double %1 } Before this patch, the instruction simplifier wrongly folded the builtin call in function @test to constant 'double 7.0'. With this patch, method 'fusedMultiplyAdd' correctly evaluates the multiply and propagates the expected result (i.e. 56.0). Added test fold-builtin-fma.ll with the reproducible from PR20832 plus extra test cases to verify the behavior of method 'fusedMultiplyAdd' in the presence of NaN/Inf operands. This fixes PR20832. llvm-svn: 219708
Diffstat (limited to 'llvm/lib/Support/APFloat.cpp')
-rw-r--r--llvm/lib/Support/APFloat.cpp4
1 files changed, 2 insertions, 2 deletions
diff --git a/llvm/lib/Support/APFloat.cpp b/llvm/lib/Support/APFloat.cpp
index 57fbe897fc8..f63d7748973 100644
--- a/llvm/lib/Support/APFloat.cpp
+++ b/llvm/lib/Support/APFloat.cpp
@@ -954,7 +954,7 @@ APFloat::multiplySignificand(const APFloat &rhs, const APFloat *addend)
// exponent accordingly.
exponent += 1;
- if (addend) {
+ if (addend && addend->isNonZero()) {
// The intermediate result of the multiplication has "2 * precision"
// signicant bit; adjust the addend to be consistent with mul result.
//
@@ -1800,7 +1800,7 @@ APFloat::fusedMultiplyAdd(const APFloat &multiplicand,
extended-precision calculation. */
if (isFiniteNonZero() &&
multiplicand.isFiniteNonZero() &&
- addend.isFiniteNonZero()) {
+ addend.isFinite()) {
lostFraction lost_fraction;
lost_fraction = multiplySignificand(multiplicand, &addend);
OpenPOWER on IntegriCloud