Commit Graph

207 Commits

Author SHA1 Message Date
Matt Arsenault ea00b499c7 APFloat: Fix signalling nans for scalbn
llvm-svn: 264219
2016-03-23 23:51:45 +00:00
Matt Arsenault c25a71106c APFloat: Add frexp
llvm-svn: 263950
2016-03-21 16:49:16 +00:00
Matt Arsenault 69fdf9b2e4 APFloat: Fix ilogb for denormals
llvm-svn: 263370
2016-03-13 05:12:32 +00:00
Matt Arsenault afa31cf4cc APFloat: Fix scalbn handling of denormals
This was incorrect for denormals, and also failed
on longer exponent ranges.

llvm-svn: 263369
2016-03-13 05:11:51 +00:00
Richard Trieu 7a08381403 Remove uses of builtin comma operator.
Cleanup for upcoming Clang warning -Wcomma.  No functionality change intended.

llvm-svn: 261270
2016-02-18 22:09:30 +00:00
Stephen Canon 1bfc89baac Add isInteger() to APFloat.
Useful utility function; this wasn't too hard to do before, but also wasn't
obviously discoverable.  Make it explicit.  Reviewed offline by Michael
Gottesman.

llvm-svn: 253254
2015-11-16 21:52:48 +00:00
Stephen Canon b12db0e42c Remove roundingMode argument in APFloat::mod
Because mod is always exact, this function should have never taken a rounding mode argument.  The actual implementation still has issues, which I'll look at resolving in a subsequent patch.

llvm-svn: 248195
2015-09-21 19:29:25 +00:00
JF Bastien a1d3c24ccf Expose more properties of llvm::fltSemantics
Summary: Adds accessor functions for all the fields in llvm::fltSemantics. This will be used in MergeFunctions to order two APFloats with different semanatics.

Author: jrkoenig
Reviewers: jfb
Subscribers: dschuff, llvm-commits
Differential revision: http://reviews.llvm.org/D12253

llvm-svn: 245999
2015-08-26 02:32:45 +00:00
Benjamin Kramer 103fc94d2d [APFloat] Remove else after return and replace loop with std::equal. NFC.
llvm-svn: 245707
2015-08-21 16:44:52 +00:00
Tamas Berghammer b6b0ddfc95 Add getSizeInBits function to the APFloat class
The newly added function returns the size of the specified floating
point semantics in bits.

Differential revision: http://reviews.llvm.org/D8413

llvm-svn: 241793
2015-07-09 10:13:39 +00:00
Alexander Kornienko f00654e31b Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC)
Apparently, the style needs to be agreed upon first.

llvm-svn: 240390
2015-06-23 09:49:53 +00:00
Alexander Kornienko 70bc5f1398 Fixed/added namespace ending comments using clang-tidy. NFC
The patch is generated using this command:

tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
  -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
  llvm/lib/


Thanks to Eugene Kosov for the original patch!

llvm-svn: 240137
2015-06-19 15:57:42 +00:00
Richard Trieu 6ae37961a8 Fix -Wpessimizing-move warnings by removing std::move calls.
llvm-svn: 236278
2015-04-30 23:07:00 +00:00
Aaron Ballman d5cc45f192 Silencing some MSVC warnings "C4805: '^' : unsafe mix of type 'bool' and type 'unsigned int' in operation"; NFC.
llvm-svn: 233067
2015-03-24 12:47:51 +00:00
David Blaikie 4f75c097b0 Refactor: Simplify boolean expressions in llvm Support
Simplify boolean expressions using `true` and `false` with `clang-tidy`

Patch by Richard Thomson - I dropped the parens and != 0 test, for
consistency with other patches/tests like this, but I'm open to the
notion that we should add the explicit non-zero test in all these sort
of cases (non-bool assigned to a bool).

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

llvm-svn: 233004
2015-03-23 19:45:40 +00:00
David Blaikie dc3f01e9cf Simplify expressions involving boolean constants with clang-tidy
Patch by Richard (legalize at xmission dot com).

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

llvm-svn: 231617
2015-03-09 01:57:13 +00:00
Lang Hames 12b12e800b [APFloat][ADT] Fix sign handling logic for FMA results that truncate to zero.
This patch adds a check for underflow when truncating results back to lower
precision at the end of an FMA. The additional sign handling logic in
APFloat::fusedMultiplyAdd should only be performed when the result of the
addition step of the FMA (in full precision) is exactly zero, not when the
result underflows to zero.

Unit tests for this case and related signed zero FMA results are included.

Fixes <rdar://problem/18925551>.

llvm-svn: 225123
2015-01-04 01:20:55 +00:00
Lang Hames 56c0eb2d90 [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
2014-11-19 19:15:41 +00:00
Hal Finkel 171c2ec008 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
2014-10-14 19:23:07 +00:00
Benjamin Kramer 7000ca3f55 Modernize old-style static asserts. NFC.
llvm-svn: 219588
2014-10-12 17:56:40 +00:00
Chandler Carruth d9edd1e2ab [ADT] Add the scalbn function for APFloat.
llvm-svn: 219473
2014-10-10 04:54:30 +00:00
Nick Lewycky 095b92e51b 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
2014-09-06 01:16:42 +00:00
Alexey Samsonov ba1ecbc7d3 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
2014-09-06 00:41:19 +00:00
Andrea Di Biagio b9de900788 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
2014-09-02 17:22:49 +00:00
Andrea Di Biagio 7676fe1878 [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
2014-09-02 16:44:56 +00:00
Dylan Noblesmith 4e69e29a72 Revert "Support/APFloat: unique_ptr-ify temp arrays"
This reverts commit rr216359.

llvm-svn: 216429
2014-08-26 02:03:33 +00:00
Dylan Noblesmith 49c758b769 Support/APFloat: unique_ptr-ify temp arrays
llvm-svn: 216359
2014-08-25 00:58:10 +00:00
Stephen Canon d327828141 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
2014-06-08 16:53:31 +00:00
Craig Topper 2617dccea2 [C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr.
llvm-svn: 206252
2014-04-15 06:32:26 +00:00
Craig Topper c10719f55d [C++11] Make use of 'nullptr' in the Support library.
llvm-svn: 205697
2014-04-07 04:17:22 +00:00
Benjamin Kramer 06f477815f APFloat: Add a move ctor and operator=
llvm-svn: 202883
2014-03-04 20:26:51 +00:00
Alp Toker cb40291100 Fix known typos
Sweep the codebase for common typos. Includes some changes to visible function
names that were misspelt.

llvm-svn: 200018
2014-01-24 17:20:08 +00:00
Alp Toker f907b891da 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
2013-12-05 05:44:44 +00:00
Eli Friedman e72f132097 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
2013-08-29 23:44:34 +00:00
Ted Kremenek b33f944f4e Revert r189442 "Change default # of digits for APFloat::toString"
This is breaking numerous Clang tests on the buildbot.

llvm-svn: 189447
2013-08-28 06:21:46 +00:00
Eli Friedman 14cede2829 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
2013-08-28 05:23:51 +00:00
Michael Gottesman b0e688e87c [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
2013-07-27 21:49:25 +00:00
Michael Gottesman 30a90eb1a5 [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
2013-07-27 21:49:21 +00:00
Eli Friedman d2eb07acae 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
2013-07-17 22:17:29 +00:00
Ulrich Weigand 1d4dbda5b9 [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
2013-07-16 13:03:25 +00:00
Michael Gottesman 94d6195fdf [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
2013-07-02 15:50:05 +00:00
Michael Gottesman 228156c04f [APFloat] Ensure that we can properly parse strings that do not have null terminators.
rdar://14323230

llvm-svn: 185397
2013-07-01 23:54:08 +00:00
Michael Gottesman 79b0967548 Revert "Revert "[APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float.""
This reverts commit r185099.

Looks like both the ppc-64 and mips bots are still failing after I reverted this
change.

Since:

1. The mips bot always performs a clean build,
2. The ppc64-bot failed again after a clean build (I asked the ppc-64
maintainers to clean the bot which they did... Thanks Will!),

I think it is safe to assume that this change was not the cause of the failures
that said builders were seeing. Thus I am recomitting.

llvm-svn: 185111
2013-06-27 21:58:19 +00:00
Michael Gottesman ccaf3321f1 Revert "[APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float."
This reverts commit r185095. This is causing a FileCheck failure on
the 3dnow intrinsics on at least the mips/ppc bots but not on the x86
bots.

Reverting while I figure out what is going on.

llvm-svn: 185099
2013-06-27 20:40:11 +00:00
Michael Gottesman 03255a1675 [APFloat] Removed APFloat constructor which initialized to either zero/NaN but allowed you to arbitrarily set the category of the float.
The category which an APFloat belongs to should be dependent on the
actual value that the APFloat has, not be arbitrarily passed in by the
user. This will prevent inconsistency bugs where the category and the
actual value in APFloat differ.

I also fixed up all of the references to this constructor (which were
only in LLVM).

llvm-svn: 185095
2013-06-27 19:50:52 +00:00
Michael Gottesman 8136c384c5 [APFloat] Convert all references to fcNormal to references to isFiniteNonZero().
Currently inside APFloat fcNormal still implies the old definition of Normal
(i.e. isFiniteNonZero) instead of the proper IEEE-754R definition that the
external method isNormal() uses.

This patch prepares for the internal switch inside APFloat by converting all
references that check if a category is fcNormal directly with an indirect call
via isFiniteNonZero().

llvm-svn: 185036
2013-06-26 23:17:28 +00:00
Michael Gottesman 40e8a187f6 [APFloat] Added support for parsing float strings which contain {inf,-inf,NaN,-NaN}.
llvm-svn: 184713
2013-06-24 09:58:05 +00:00
Michael Gottesman c4facdf390 [APFloat] Added make{Zero,Inf} methods and implemented get{Zero,Inf} on top of them.
llvm-svn: 184712
2013-06-24 09:58:02 +00:00
Michael Gottesman f0e8cd1a7f [APFloat] Removed a assert from significandParts() which says that one can only access the significand of FiniteNonZero/NaN floats.
The method significandParts() is a helper method meant to ease access to
APFloat's significand by allowing the user to not need to be aware of whether or
not the APFloat is using memory allocated in the instance itself or in an
external array.

This assert says that one can only access the significand of FiniteNonZero/NaN
floats. This makes it cumbersome and more importantly dangerous when one wishes
to zero out the significand of a zero/infinity value since one will have to deal
with the aforementioned quandary related to how the memory in APFloat is
allocated.

llvm-svn: 184711
2013-06-24 09:57:59 +00:00
Michael Gottesman 9b877e18a3 [APFloat] Rename macro convolve => PackCategoriesIntoKey so that it is clear what APFloat is actually using said macro for.
In the context of APFloat, seeing a macro called convolve suggests that APFloat
is using said value in some sort of convolution somewhere in the source code.
This is misleading.

I also added a documentation comment to the macro.

llvm-svn: 184710
2013-06-24 09:57:57 +00:00