| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This is breaking numerous Clang tests on the buildbot.
llvm-svn: 189447
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
terminators.
rdar://14323230
llvm-svn: 185397
|
|
|
|
|
|
| |
result categories, and result statuses.
llvm-svn: 185050
|
|
|
|
| |
llvm-svn: 185045
|
|
|
|
|
|
| |
result categories, and result status.
llvm-svn: 185044
|
|
|
|
|
|
| |
result categories, and result status.
llvm-svn: 185043
|
|
|
|
| |
llvm-svn: 184974
|
|
|
|
| |
llvm-svn: 184715
|
|
|
|
|
|
| |
values are computed correctly.
llvm-svn: 184714
|
|
|
|
|
|
|
|
| |
The old isNormal is already functionally replaced by the method isFiniteNonZero
in r184350 and all references to said method were replaced in LLVM/clang in
r184356/134366.
llvm-svn: 184449
|
|
|
|
| |
llvm-svn: 184447
|
|
|
|
|
|
|
|
| |
tests in unittests.
I forgot to to do this in r184356. The only references were in APFloatTest.cpp.
llvm-svn: 184366
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the first patch in a series of patches to rename isNormal =>
isFiniteNonZero and isIEEENormal => isNormal. In order to prevent careless
errors on my part the overall plan is:
1. Add the isFiniteNonZero predicate with tests. I can do this in a method
independent of isNormal. (This step is this patch).
2. Convert all references to isNormal with isFiniteNonZero. My plan is to
comment out isNormal locally and continually convert isNormal references =>
isFiniteNonZero until llvm/clang compiles.
3. Remove old isNormal and rename isIEEENormal to isNormal.
4. Look through all of said references from patch 2 and see if we can simplify
them by using the new isNormal.
llvm-svn: 184350
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Specifically the following work was done:
1. If the operation was not implemented, I implemented it.
2. If the operation was already implemented, I just moved its location
in the APFloat header into the IEEE-754R 5.7.2 section. If the name was
incorrect, I put in a comment giving the true IEEE-754R name.
Also unittests have been added for all of the functions which did not
already have a unittest.
llvm-svn: 183179
|
|
|
|
| |
llvm-svn: 183081
|
|
|
|
| |
llvm-svn: 183028
|
|
|
|
|
|
|
|
| |
function APFloat::next(bool nextDown).
rdar://13852078
llvm-svn: 182945
|
|
|
|
| |
llvm-svn: 182897
|
|
|
|
|
|
|
|
|
| |
consider the result to be denormal.
I additionally changed certain checks to use EXPECT_FALSE instead of a boolean
complement with EXPECT_TRUE.
llvm-svn: 182896
|
|
|
|
| |
llvm-svn: 182894
|
|
|
|
|
|
| |
-14.5f + 225.0f" to 225.0f.
llvm-svn: 181715
|
|
|
|
|
|
|
|
| |
smaller type.
Fixes PR15054.
llvm-svn: 173459
|
|
|
|
| |
llvm-svn: 171764
|
|
|
|
| |
llvm-svn: 169250
|
|
|
|
|
|
|
|
| |
fmul transform.
This is safe for x87 long doubles and ppc double doubles too.
llvm-svn: 167582
|
|
|
|
|
|
|
|
|
|
|
|
| |
treating it as if it were an IEEE floating-point type with 106-bit
mantissa.
This makes compile-time arithmetic on "long double" for PowerPC
in clang (in particular parsing of floating point constants)
work, and fixes all "long double" related failures in the test
suite.
llvm-svn: 166951
|
|
|
|
|
|
|
|
| |
date, don't rely on it.
Add a couple of unit tests for special floats. Fixes 13929, found by MemorySanitizer.
llvm-svn: 164698
|
|
|
|
|
|
| |
infinity. Problem and solution identified by Steve Canon.
llvm-svn: 161969
|
|
|
|
|
|
| |
results for negative inputs to trunc. Add unit tests to verify this behavior.
llvm-svn: 161929
|
|
|
|
|
|
|
|
| |
was returning incorrect values in rare cases, and incorrectly marking
exact conversions as inexact in some more common cases. Fixes PR11406, and a
missed optimization in test/CodeGen/X86/fp-stack-O0.ll.
llvm-svn: 145141
|
|
|
|
| |
llvm-svn: 141831
|
|
|
|
|
|
| |
Found by accident while reviewing a patch to nearby code.
llvm-svn: 141816
|
|
|
|
|
|
|
|
| |
The APFloat "Zero" test was actually calling the
APFloat(const fltSemantics &, integerPart) constructor, and EXPECT_EQ was
treating 0 and -0 as equal.
llvm-svn: 138745
|
|
|
|
|
|
| |
memory for the result.
llvm-svn: 135259
|
|
|
|
|
|
|
|
|
| |
denormal multiplication.
Some platforms may treat denormals as zero, on other platforms multiplication
with a subnormal is slower than dividing by a normal.
llvm-svn: 128555
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea is, that if an ieee 754 float is divided by a power of two, we can
turn the division into a cheaper multiplication. This function sees if we can
get an exact multiplicative inverse for a divisor and returns it if possible.
This is the hard part of PR9587.
I tested many inputs against llvm-gcc's frotend implementation of this
optimization and didn't find any difference. However, floating point is the
land of weird edge cases, so any review would be appreciated.
llvm-svn: 128545
|
|
|
|
| |
llvm-svn: 98701
|
|
|
|
|
|
|
|
| |
payloads. APFloat's internal folding routines always make QNaNs now,
instead of sometimes making QNaNs and sometimes SNaNs depending on the
type.
llvm-svn: 97364
|
|
|
|
| |
llvm-svn: 97278
|
|
|
|
|
|
| |
as undefined. Fixes an assertion in APFloat::toString noticed by Dale.
llvm-svn: 95196
|
|
|
|
|
|
| |
major bugs in long-precision conversion.
llvm-svn: 92150
|
|
|
|
|
|
|
|
| |
smallest-normalized-magnitude values in a given FP semantics.
Provide an APFloat-to-string conversion which I am quite ready to admit could
be much more efficient.
llvm-svn: 92126
|
|
|
|
| |
llvm-svn: 80965
|
|
|
|
|
|
| |
and many new unit tests.
llvm-svn: 79574
|
|
|
|
| |
llvm-svn: 79540
|