summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/APFloat.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Revert "r216914 - Revert: [APFloat] Fixed a bug in method 'fusedMultiplyAdd'"Hal Finkel2014-10-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Modernize old-style static asserts. NFC.Benjamin Kramer2014-10-121-2/+1
| | | | llvm-svn: 219588
* [ADT] Add the scalbn function for APFloat.Chandler Carruth2014-10-101-0/+17
| | | | llvm-svn: 219473
* Check whether the iterator p == the end iterator before trying to ↵Nick Lewycky2014-09-061-3/+3
| | | | | | 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.cppAlexey Samsonov2014-09-061-1/+3
| | | | | | | | 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'.Andrea Di Biagio2014-09-021-1/+1
| | | | | | | 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'.Andrea Di Biagio2014-09-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert "Support/APFloat: unique_ptr-ify temp arrays"Dylan Noblesmith2014-08-261-8/+11
| | | | | | This reverts commit rr216359. llvm-svn: 216429
* Support/APFloat: unique_ptr-ify temp arraysDylan Noblesmith2014-08-251-11/+8
| | | | llvm-svn: 216359
* APFloat: x - NaN needs to flip the signbit of NaN when x is a number.Stephen Canon2014-06-081-1/+3
| | | | | | 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
* [C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper2014-04-151-6/+6
| | | | | | instead of comparing to nullptr. llvm-svn: 206252
* [C++11] Make use of 'nullptr' in the Support library.Craig Topper2014-04-071-3/+3
| | | | llvm-svn: 205697
* APFloat: Add a move ctor and operator=Benjamin Kramer2014-03-041-0/+18
| | | | llvm-svn: 202883
* Fix known typosAlp Toker2014-01-241-1/+1
| | | | | | | Sweep the codebase for common typos. Includes some changes to visible function names that were misspelt. llvm-svn: 200018
* Correct word hyphenationsAlp Toker2013-12-051-1/+1
| | | | | | | 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::toStringEli Friedman2013-08-291-5/+8
| | | | | | | | | | | | | | | | | 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
* Revert r189442 "Change default # of digits for APFloat::toString"Ted Kremenek2013-08-281-8/+5
| | | | | | This is breaking numerous Clang tests on the buildbot. llvm-svn: 189447
* Change default # of digits for APFloat::toStringEli Friedman2013-08-281-5/+8
| | | | | | | | | | | | | | | 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
* [APFloat] Make all arithmetic operations with NaN produce positive NaNs.Michael Gottesman2013-07-271-7/+10
| | | | | | | | | | | | | 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
* [APFloat] Move setting fcNormal in zeroSignificand() to calling code.Michael Gottesman2013-07-271-2/+4
| | | | | | | | 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
* Handle '.' correctly in hex float literal parsing.Eli Friedman2013-07-171-30/+20
| | | | | | | | | | | 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
* [APFloat] PR16573: Avoid losing mantissa bits in ppc_fp128 to double truncationUlrich Weigand2013-07-161-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [APFloat] Swap an early out check so we do not dereference str.end().Michael Gottesman2013-07-021-1/+1
| | | | | | | Originally if D.firstSigDigit == str.end(), we will have already dereferenced D.firstSigDigit in the first predicate. llvm-svn: 185437
* [APFloat] Ensure that we can properly parse strings that do not have null ↵Michael Gottesman2013-07-011-1/+8
| | | | | | | | terminators. rdar://14323230 llvm-svn: 185397
* Revert "Revert "[APFloat] Removed APFloat constructor which initialized to ↵Michael Gottesman2013-06-271-15/+5
| | | | | | | | | | | | | | | | | | | | 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
* Revert "[APFloat] Removed APFloat constructor which initialized to either ↵Michael Gottesman2013-06-271-5/+15
| | | | | | | | | | | | 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
* [APFloat] Removed APFloat constructor which initialized to either zero/NaN ↵Michael Gottesman2013-06-271-15/+5
| | | | | | | | | | | | | | 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
* [APFloat] Convert all references to fcNormal to references to isFiniteNonZero().Michael Gottesman2013-06-261-30/+30
| | | | | | | | | | | | 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
* [APFloat] Added support for parsing float strings which contain ↵Michael Gottesman2013-06-241-0/+29
| | | | | | {inf,-inf,NaN,-NaN}. llvm-svn: 184713
* [APFloat] Added make{Zero,Inf} methods and implemented get{Zero,Inf} on top ↵Michael Gottesman2013-06-241-0/+16
| | | | | | of them. llvm-svn: 184712
* [APFloat] Removed a assert from significandParts() which says that one can ↵Michael Gottesman2013-06-241-2/+0
| | | | | | | | | | | | | | | | | 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
* [APFloat] Rename macro convolve => PackCategoriesIntoKey so that it is clear ↵Michael Gottesman2013-06-241-86/+92
| | | | | | | | | | | | 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
* [APFloat] Rename llvm::exponent_t => llvm::APFloat::ExponentType.Michael Gottesman2013-06-241-5/+5
| | | | | | | | | exponent_t is only used internally in APFloat and no exponent_t values are exposed via the APFloat API. In light of such conditions it does not make any sense to gum up the llvm namespace with said type. Plus it makes it clearer that exponent_t is associated with APFloat. llvm-svn: 184686
* [APFloat] Converted all references to APFloat::isNormal => ↵Michael Gottesman2013-06-191-3/+3
| | | | | | | | APFloat::isFiniteNonZero. Turns out all the references were in llvm and not in clang. llvm-svn: 184356
* Fixed comment typo that causes the given comment to actually make sense.Michael Gottesman2013-06-191-1/+1
| | | | llvm-svn: 184286
* Introduce needsCleanup() for APFloat and APInt.Manuel Klimek2013-06-031-1/+1
| | | | | | | | | This is needed in clang so one can check if the object needs the destructor called after its memory was freed. This is useful when creating many APInt/APFloat objects with placement new, where the overhead of tracking the pointers for cleanup is significant. llvm-svn: 183100
* APFloat: Use isDenormal instead of hand-rolled code to check for denormals.Benjamin Kramer2013-06-011-1/+1
| | | | llvm-svn: 183072
* Implement IEEE-754R 2008 nextUp/nextDown functions in the guise of the ↵Michael Gottesman2013-05-301-20/+228
| | | | | | | | function APFloat::next(bool nextDown). rdar://13852078 llvm-svn: 182945
* Fix a bug that APFloat::fusedMultiplyAdd() mistakenly evaluate "14.5f * ↵Shuxin Yang2013-05-131-2/+27
| | | | | | -14.5f + 225.0f" to 225.0f. llvm-svn: 181715
* Fix AsmPrinter crashes with assertion. Bug 15318 in BugzillaHao Liu2013-03-201-4/+2
| | | | llvm-svn: 177472
* APFloat: Make sure that we get a well-formed x87 NaN when converting from a ↵Benjamin Kramer2013-01-251-0/+6
| | | | | | | | smaller type. Fixes PR15054. llvm-svn: 173459
* Make APFloat constructor require explicit semantics.Tim Northover2013-01-221-16/+32
| | | | | | | | | Previously we tried to infer it from the bit width size, with an added IsIEEE argument for the PPC/IEEE 128-bit case, which had a default value. This default value allowed bugs to creep in, where it was inappropriate. llvm-svn: 173138
* Add llvm::hexDigitValue to convert single characters to hex.Jordan Rose2013-01-181-20/+1
| | | | | | This is duplicated in a couple places in the codebase. Adopt this in APFloat. llvm-svn: 172851
* Remove redundant 'llvm::' qualificationsDmitri Gribenko2013-01-131-1/+1
| | | | llvm-svn: 172358
* Implement APFloat::isDenormal()Shuxin Yang2013-01-071-0/+7
| | | | llvm-svn: 171764
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-1/+1
| | | | | | | | | | | | | | | | | Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
* Fix a bug in APFloat.cpp: declare APFloat after fltSemantics itAlexey Samsonov2012-11-301-1/+3
| | | | | | | | | | | uses. APFloat::convert() takes the pointer to the fltSemantics variable, which is later accessed it in ~APFloat() desctructor. That is, semantics must still be alive at the moment we delete APFloat. Found by experimental AddressSanitizer use-after-scope checker. llvm-svn: 169047
* Drop the limitation to IEEE floating point types from the fdiv of pow2 -> ↵Benjamin Kramer2012-11-081-5/+0
| | | | | | | | fmul transform. This is safe for x87 long doubles and ppc double doubles too. llvm-svn: 167582
* APFloat cleanup: Remove now unused "arithmeticOK" logic.Ulrich Weigand2012-10-291-42/+8
| | | | llvm-svn: 166954
* APFloat cleanup: Remove now unused fields "sign2" and "exponent2".Ulrich Weigand2012-10-291-21/+9
| | | | llvm-svn: 166952
OpenPOWER on IntegriCloud