[ADT] Fix PR20728 - Incorrect APFloat::fusedMultiplyAdd results for x86_fp80.

As detailed at http://llvm.org/PR20728, due to an internal overflow in
APFloat::multiplySignificand the APFloat::fusedMu

[ADT] Fix PR20728 - Incorrect APFloat::fusedMultiplyAdd results for x86_fp80.

As detailed at http://llvm.org/PR20728, due to an internal overflow in
APFloat::multiplySignificand the APFloat::fusedMultiplyAdd method can return
incorrect results for x87DoubleExtended (x86_fp80) values. This commonly
manifests as incorrect constant folding of libm fmal calls on x86. E.g.

fmal(1.0L, 1.0L, 3.0L) == 0.0L (should be 4.0L)

This patch fixes PR20728 by adding an extra bit to the significand for
intermediate results of APFloat::multiplySignificand, avoiding the overflow.

llvm-svn: 222374

show more ...

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

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

show more ...

Modernize old-style static asserts. NFC.

llvm-svn: 219588

[ADT] Add the scalbn function for APFloat.

llvm-svn: 219473

Check whether the iterator p == the end iterator before trying to dereference it. This is a speculative fix for a failure found on the valgrind buildbot triggered by a clang test.

llvm-svn: 217295

Fix right shift by 64 bits detected on CXX/lex/lex.literal/lex.ext/p4.cpp
test case on UBSan bootstrap bot.

This fixes the last failure of "check-clang" in UBSan bootstrap bot.

llvm-svn: 217294

Revert: [APFloat] Fixed a bug in method 'fusedMultiplyAdd'.

This reverts revision 216913; the new test added at revision 216913
caused regression failures on a couple of buildbots.

llvm-svn: 216914

[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 o

[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.

Differential Revision: http://reviews.llvm.org/D5152

llvm-svn: 216913

show more ...

Revert "Support/APFloat: unique_ptr-ify temp arrays"

This reverts commit rr216359.

llvm-svn: 216429

Support/APFloat: unique_ptr-ify temp arrays

llvm-svn: 216359

APFloat: x - NaN needs to flip the signbit of NaN when x is a number.

Because we don't have a separate negate( ) function, 0 - NaN does double-duty as the IEEE-754 negate( ) operation, which (unlike

APFloat: x - NaN needs to flip the signbit of NaN when x is a number.

Because we don't have a separate negate( ) function, 0 - NaN does double-duty as the IEEE-754 negate( ) operation, which (unlike most FP ops) *does* attach semantic meaning to the signbit of NaN.

llvm-svn: 210428

show more ...

[C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr.

llvm-svn: 206252

[C++11] Make use of 'nullptr' in the Support library.

llvm-svn: 205697

APFloat: Add a move ctor and operator=

llvm-svn: 202883

Fix known typos

Sweep the codebase for common typos. Includes some changes to visible function
names that were misspelt.

llvm-svn: 200018

Correct word hyphenations

This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities and contractions in nearby lines.

llvm-svn: 196471

Change default # of digits for APFloat::toString

This is a re-commit of r189442; I'll follow up with clang changes.

The previous default was almost, but not quite enough digits to
represent a float

Change default # of digits for APFloat::toString

This is a re-commit of r189442; I'll follow up with clang changes.

The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in. The larger default is much
less confusing.

I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which). I have a WIP patch if anyone is interested.

llvm-svn: 189624

show more ...

Revert r189442 "Change default # of digits for APFloat::toString"

This is breaking numerous Clang tests on the buildbot.

llvm-svn: 189447

Change default # of digits for APFloat::toString

The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when

Change default # of digits for APFloat::toString

The previous default was almost, but not quite enough digits to
represent a floating-point value in a manner which preserves the
representation when it's read back in. The larger default is much
less confusing.

I spent some time looking into printing exactly the right number of
digits if a precision isn't specified, but it's kind of complicated,
and I'm not really sure I understand what APFloat::toString is supposed
to output for FormatPrecision != 0 (or maybe the current API specification
is just silly, not sure which). I have a WIP patch if anyone is interested.

llvm-svn: 189442

show more ...

[APFloat] Make all arithmetic operations with NaN produce positive NaNs.

IEEE-754R 1.4 Exclusions states that IEEE-754R does not specify the
interpretation of the sign of NaNs. In order to remove an

[APFloat] Make all arithmetic operations with NaN produce positive NaNs.

IEEE-754R 1.4 Exclusions states that IEEE-754R does not specify the
interpretation of the sign of NaNs. In order to remove an irrelevant
variable that most floating point implementations do not use,
standardize add, sub, mul, div, mod so that operating anything with
NaN always yields a positive NaN.

In a later commit I am going to update the APIs for creating NaNs so
that one can not even create a negative NaN.

llvm-svn: 187314

show more ...

[APFloat] Move setting fcNormal in zeroSignificand() to calling code.

Zeroing the significand of a floating point number does not necessarily cause a
floating point number to become finite non zero.

[APFloat] Move setting fcNormal in zeroSignificand() to calling code.

Zeroing the significand of a floating point number does not necessarily cause a
floating point number to become finite non zero. For instance, if one has a NaN,
zeroing the significand will cause it to become +/- infinity.

llvm-svn: 187313

show more ...

Handle '.' correctly in hex float literal parsing.

There were a couple of different loops that were not handling
'.' correctly in APFloat::convertFromHexadecimalString; these mistakes
could lead to

Handle '.' correctly in hex float literal parsing.

There were a couple of different loops that were not handling
'.' correctly in APFloat::convertFromHexadecimalString; these mistakes
could lead to assertion failures and incorrect rounding for overlong
hex float literals.

Fixes PR16643.

llvm-svn: 186539

show more ...

[APFloat] PR16573: Avoid losing mantissa bits in ppc_fp128 to double truncation

When truncating to a format with fewer mantissa bits, APFloat::convert
will perform a right shift of the mantissa by t

[APFloat] PR16573: Avoid losing mantissa bits in ppc_fp128 to double truncation

When truncating to a format with fewer mantissa bits, APFloat::convert
will perform a right shift of the mantissa by the difference of the
precision of the two formats. Usually, this will result in just the
mantissa bits needed for the target format.

One special situation is if the input number is denormal. In this case,
the right shift may discard significant bits. This is usually not a
problem, since truncating a denormal usually results in zero (underflow)
after normalization anyway, since the result format's exponent range is
usually smaller than the target format's.

However, there is one case where the latter property does not hold:
when truncating from ppc_fp128 to double. In particular, truncating
a ppc_fp128 whose first double of the pair is denormal should result
in just that first double, not zero. The current code however
performs an excessive right shift, resulting in lost result bits.
This is then caught in the APFloat::normalize call performed by
APFloat::convert and causes an assertion failure.

This patch checks for the scenario of truncating a denormal, and
attempts to (possibly partially) replace the initial mantissa
right shift by decrementing the exponent, if doing so will still
result in a valid *target format* exponent.


Index: test/CodeGen/PowerPC/pr16573.ll
===================================================================
--- test/CodeGen/PowerPC/pr16573.ll (revision 0)
+++ test/CodeGen/PowerPC/pr16573.ll (revision 0)
@@ -0,0 +1,11 @@
+; RUN: llc < %s | FileCheck %s
+
+target triple = "powerpc64-unknown-linux-gnu"
+
+define double @test() {
+ %1 = fptrunc ppc_fp128 0xM818F2887B9295809800000000032D000 to double
+ ret double %1
+}
+
+; CHECK: .quad -9111018957755033591
+
Index: lib/Support/APFloat.cpp
===================================================================
--- lib/Support/APFloat.cpp (revision 185817)
+++ lib/Support/APFloat.cpp (working copy)
@@ -1956,6 +1956,23 @@
X86SpecialNan = true;
}

+ // If this is a truncation of a denormal number, and the target semantics
+ // has larger exponent range than the source semantics (this can happen
+ // when truncating from PowerPC double-double to double format), the
+ // right shift could lose result mantissa bits. Adjust exponent instead
+ // of performing excessive shift.
+ if (shift < 0 && isFiniteNonZero()) {
+ int exponentChange = significandMSB() + 1 - fromSemantics.precision;
+ if (exponent + exponentChange < toSemantics.minExponent)
+ exponentChange = toSemantics.minExponent - exponent;
+ if (exponentChange < shift)
+ exponentChange = shift;
+ if (exponentChange < 0) {
+ shift -= exponentChange;
+ exponent += exponentChange;
+ }
+ }
+
// If this is a truncation, perform the shift before we narrow the storage.
if (shift < 0 && (isFiniteNonZero() || category==fcNaN))
lostFraction = shiftRight(significandParts(), oldPartCount, -shift);

llvm-svn: 186409

show more ...

[APFloat] Swap an early out check so we do not dereference str.end().

Originally if D.firstSigDigit == str.end(), we will have already dereferenced
D.firstSigDigit in the first predicate.

llvm-svn:

[APFloat] Swap an early out check so we do not dereference str.end().

Originally if D.firstSigDigit == str.end(), we will have already dereferenced
D.firstSigDigit in the first predicate.

llvm-svn: 185437

show more ...

[APFloat] Ensure that we can properly parse strings that do not have null terminators.

rdar://14323230

llvm-svn: 185397