We had various variants of defining dump() functions in LLVM. Normalize
them (this should just consistently implement the things discussed in
http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html
For reference:
- Public headers should just declare the dump() method but not use
LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
- The definition of a dump method should look like this:
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
LLVM_DUMP_METHOD void MyClass::dump() {
// print stuff to dbgs()...
}
#endif
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293359 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: This is an attempt to reduce the verbose manual dispatching code in APFloat. This doesn't handle multiple dispatch on single discriminator (e.g. APFloat::add(const APFloat&)), nor handles multiple dispatch on multiple discriminators (e.g. APFloat::convert()).
Reviewers: hfinkel, echristo, jlebar
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D29161
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293255 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch changes the layout of DoubleAPFloat, and adjust all
operations to do either:
1) (IEEEdouble, IEEEdouble) -> (uint64_t, uint64_t) -> PPCDoubleDoubleImpl,
then run the old algorithm.
2) Do the right thing directly.
1) includes multiply, divide, remainder, mod, fusedMultiplyAdd, roundToIntegral,
convertFromString, next, convertToInteger, convertFromAPInt,
convertFromSignExtendedInteger, convertFromZeroExtendedInteger,
convertToHexString, toString, getExactInverse.
2) includes makeZero, makeLargest, makeSmallest, makeSmallestNormalized,
compare, bitwiseIsEqual, bitcastToAPInt, isDenormal, isSmallest,
isLargest, isInteger, ilogb, scalbn, frexp, hash_value, Profile.
I could split this into two patches, e.g. use
1) for all operatoins first, then incrementally change some of them to
2). I didn't do that, because 1) involves code that converts data between
PPCDoubleDoubleImpl and (IEEEdouble, IEEEdouble) back and forth, and may
pessimize the compiler. Instead, I find easy functions and use
approach 2) for them directly.
Next step is to implement move multiply and divide from 1) to 2). I don't
have plans for other functions in 1).
Differential Revision: https://reviews.llvm.org/D27872
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@292839 91177308-0d34-0410-b5e6-96231b3b80d8
Provide a distinct contents for semBogus and semPPCDoubleDouble in order
to prevent compilers from collapsing them to a single memory address,
while we heavily rely on every semantic having distinct address.
This happens if insecure optimization collapsing identical values is
enabled. As a result, APFloats of semBogus are indistinguishable from
semPPCDoubleDouble -- and whenever the move constructor is used, the old
value beings being incorrectly recognized as a semPPCDoubleDouble.
Since the values in semPPCDoubleDouble are not used anywhere,
we can easily solve this issue via altering the value of one of the
fields and therefore ensuring that the collapse can not occur.
Differential Revision: https://reviews.llvm.org/D28112
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290896 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
I looked at libgcc's implementation (which is based on the paper,
Software for Doubled-Precision Floating-Point Computations", by Seppo Linnainmaa,
ACM TOMS vol 7 no 3, September 1981, pages 272-283.) and made it generic to
arbitrary IEEE floats.
Differential Revision: https://reviews.llvm.org/D26817
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@289472 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Fixes PR30869.
In D25977 I meant to change all functions that care about lifetime. I
changed constructors, factory functions, but I missed member/free
functions that return new instances. This patch changes them.
Reviewers: hfinkel, kbarton, echristo, joerg
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D26269
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@286060 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch adds DoubleAPFloat mode to APFloat.
Now, an APFloat with semantics PPCDoubleDouble will have DoubleAPFloat layout
(APFloat.U.Double), which contains two underlying APFloats as
PPCDoubleDoubleImpl and IEEEdouble semantics. Currently the IEEEdouble APFloat
is not used, and the first APFloat behaves exactly the same before this change.
This patch consists of three kinds of logics:
1) Construction and destruction of APFloat. Now the ctors, dtor, assign
opertors and factory functions construct different underlying layout
based on the semantics passed in.
2) s/IEEE/getIEEE()/ for normal, lifetime-unrelated computation functions.
These functions only access Floats[0] in DoubleAPFloat, which is the
same as today's semantic.
3) A "Double dispatch" function, APFloat::convert. Converting between two
different layouts requires appropriate logic.
Neither of these change the external behavior.
Reviewers: hfinkel, kbarton, echristo, iteratee
Subscribers: mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D25977
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285351 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The intention is to make APFloat an interface class, so that later I can add a second implementation class DoubleAPFloat to correctly implement PPCDoubleDouble semantic. The interface of IEEEFloat is not public, and can be simplified (currently it's exactly the same as the old APFloat), but that belongs to a separate patch.
DoubleAPFloat should look like:
class DoubleAPFloat {
const fltSemantics *Semantics;
std::unique_ptr<APFloat> APFloats; // Two heap-allocated APFloats.
};
There is no functional change, nor public interface change.
Reviewers: hfinkel, chandlerc, iteratee, echristo, kbarton
Subscribers: llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25536
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285105 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253254 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@248195 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245999 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@240137 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233004 91177308-0d34-0410-b5e6-96231b3b80d8
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>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225123 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222374 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@219708 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts revision 216913; the new test added at revision 216913
caused regression failures on a couple of buildbots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216914 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216913 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210428 91177308-0d34-0410-b5e6-96231b3b80d8
