Revision tags: llvmorg-21-init, llvmorg-19.1.7 |
|
#
ad56f626 |
| 13-Jan-2025 |
Congcong Cai <congcongcai0907@163.com> |
[APFloat][NFC]extract `fltSemantics::isRepresentableBy` to header (#122636)
isRepresentableBy is useful to check float point type compatibility
|
Revision tags: llvmorg-19.1.6 |
|
#
f50ce316 |
| 04-Dec-2024 |
Matthias Springer <me@m-sp.org> |
[llvm][NFC] `APFloat`: Add missing semantics to enum (#117291)
* Add missing semantics to the `Semantics` enum.
* Move all documentation of the semantics to the header file.
* Also rename some fun
[llvm][NFC] `APFloat`: Add missing semantics to enum (#117291)
* Add missing semantics to the `Semantics` enum.
* Move all documentation of the semantics to the header file.
* Also rename some functions for consistency.
show more ...
|
Revision tags: llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
309c8909 |
| 16-Nov-2024 |
Matthias Springer <me@m-sp.org> |
[llvm] `APFloat`: Add helpers to query NaN/inf semantics (#116315)
`APFloat` changes extracted from #116176 as per reviewer comments.
|
#
2f55de4e |
| 15-Nov-2024 |
Matthias Springer <me@m-sp.org> |
[llvm] `APFloat`: Query `hasNanOrInf` from semantics (#116158)
Whether a floating point type supports NaN or infinity can be queried
from its semantics. No need to hard-code a list of types.
|
#
4048c643 |
| 12-Nov-2024 |
Kazu Hirata <kazu@google.com> |
[llvm] Remove redundant control flow statements (NFC) (#115831)
Identified with readability-redundant-control-flow.
|
Revision tags: llvmorg-19.1.3 |
|
#
7b308b18 |
| 22-Oct-2024 |
Sergey Kozub <skozub@nvidia.com> |
Fix bitcasting E8M0 APFloat to APInt (#113298)
Fixes a bug in APFloat handling of E8M0 type (zero mantissa).
Related PRs:
- https://github.com/llvm/llvm-project/pull/107127
- https://github.com
Fix bitcasting E8M0 APFloat to APInt (#113298)
Fixes a bug in APFloat handling of E8M0 type (zero mantissa).
Related PRs:
- https://github.com/llvm/llvm-project/pull/107127
- https://github.com/llvm/llvm-project/pull/111028
show more ...
|
Revision tags: llvmorg-19.1.2 |
|
#
3b7091bc |
| 09-Oct-2024 |
Ariel-Burton <arielburton@yahoo.com> |
[APFloat] add predicates to fltSemantics for hasZero and hasSignedRepr (#111451)
We add static methods to APFloatBase to allow the hasZero and
hasSignedRepr properties of fltSemantics to be obtaine
[APFloat] add predicates to fltSemantics for hasZero and hasSignedRepr (#111451)
We add static methods to APFloatBase to allow the hasZero and
hasSignedRepr properties of fltSemantics to be obtained.
show more ...
|
#
6004f555 |
| 09-Oct-2024 |
Yingwei Zheng <dtcxzyw2333@gmail.com> |
[ADT][APFloat] Make sure EBO is performed on APFloat (#111641)
Since both APFloat and (Double)IEEEFloat inherit from APFloatBase, empty
base optimization is not performed by GCC/Clang (Minimal repr
[ADT][APFloat] Make sure EBO is performed on APFloat (#111641)
Since both APFloat and (Double)IEEEFloat inherit from APFloatBase, empty
base optimization is not performed by GCC/Clang (Minimal reproducer:
https://godbolt.org/z/dY8cM3Wre). This patch removes inheritance
relation between (Double)IEEEFloat and APFloatBase to make sure EBO is
performed on APFloat. After this patch, the size of `ConstantFPRange`
will be reduced from 72 to 56.
Address comment
https://github.com/llvm/llvm-project/pull/111544#discussion_r1792398427.
show more ...
|
#
99f527d2 |
| 02-Oct-2024 |
Durgadoss R <durgadossr@nvidia.com> |
[APFloat] Add APFloat support for E8M0 type (#107127)
This patch adds an APFloat type for unsigned E8M0 format. This format is
used for representing the "scale-format" in the MX specification:
(se
[APFloat] Add APFloat support for E8M0 type (#107127)
This patch adds an APFloat type for unsigned E8M0 format. This format is
used for representing the "scale-format" in the MX specification:
(section 5.4)
https://www.opencompute.org/documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf
This format does not support {Inf, denorms, zeroes}. Like FP32, this
format's exponents are 8-bits (all bits here) and the bias value is 127.
However, it differs from IEEE-FP32 in that the minExponent is -127
(instead of -126). There are updates done in the APFloat utility
functions to handle these constraints for this format.
* The bias calculation is different and convertIEEE* APIs are updated to
handle this.
* Since there are no significand bits, the isSignificandAll{Zeroes/Ones}
methods are updated accordingly.
* Although the format does not have any precision, the precision bit in
the fltSemantics is set to 1 for consistency with APFloat's internal
representation.
* Many utility functions are updated to handle the fact that this format
does not support Zero.
* Provide a separate initFromAPInt() implementation to handle the quirks
of the format.
* Add specific tests to verify the range of values for this format.
Signed-off-by: Durgadoss R <durgadossr@nvidia.com>
show more ...
|
Revision tags: llvmorg-19.1.1 |
|
#
fa824dc0 |
| 25-Sep-2024 |
Yingwei Zheng <dtcxzyw2333@gmail.com> |
[LLVM][IR] Add constant range support for floating-point types (#86483)
This patch adds basic constant range support for floating-point types to enable range-based optimizations.
|
Revision tags: llvmorg-19.1.0, llvmorg-19.1.0-rc4 |
|
#
3ef64f7a |
| 24-Aug-2024 |
NAKAMURA Takumi <geek4civic@gmail.com> |
Revert "Enable logf128 constant folding for hosts with 128bit long double (#104929)"
ConstantFolding behaves differently depending on host's `HAS_IEE754_FLOAT128`. LLVM should not change the behavio
Revert "Enable logf128 constant folding for hosts with 128bit long double (#104929)"
ConstantFolding behaves differently depending on host's `HAS_IEE754_FLOAT128`. LLVM should not change the behavior depending on host configurations.
This reverts commit 14c7e4a1844904f3db9b2dc93b722925a8c66b27. (llvmorg-20-init-3262-g14c7e4a18449 and llvmorg-20-init-3498-g001e423ac626)
show more ...
|
#
14c7e4a1 |
| 22-Aug-2024 |
Matthew Devereau <matthew.devereau@arm.com> |
Enable logf128 constant folding for hosts with 128bit long double (#104929)
This is a reland of (#96287). This patch attempts to reduce the reverted
patch's clang compile time by removing #includes
Enable logf128 constant folding for hosts with 128bit long double (#104929)
This is a reland of (#96287). This patch attempts to reduce the reverted
patch's clang compile time by removing #includes of float128.h and
inlining convertToQuad functions instead.
show more ...
|
Revision tags: llvmorg-19.1.0-rc3 |
|
#
6300233d |
| 14-Aug-2024 |
Nikita Popov <npopov@redhat.com> |
Revert "Reland logf128 constant folding (#103217)"
This reverts commit 3cab7c555ad6451f2b1b4dc918a4b4f4e4a3e45d.
The modified test fails on ppc64le buildbots.
|
#
3cab7c55 |
| 14-Aug-2024 |
Matthew Devereau <matthew.devereau@arm.com> |
Reland logf128 constant folding (#103217)
This is a reland of #96287. This change makes tests in logf128.ll ignore
the sign of NaNs for negative value tests and moves an #include <cmath>
to be blo
Reland logf128 constant folding (#103217)
This is a reland of #96287. This change makes tests in logf128.ll ignore
the sign of NaNs for negative value tests and moves an #include <cmath>
to be blocked behind #ifndef _GLIBCXX_MATH_H.
show more ...
|
#
a15de177 |
| 09-Aug-2024 |
Nikita Popov <npopov@redhat.com> |
Revert "Enable logf128 constant folding for hosts with 128bit floats (#96287)"
This reverts commit ccb2b011e577e861254f61df9c59494e9e122b38.
Causes buildbot failures, e.g. on ppc64le builders.
|
#
ccb2b011 |
| 09-Aug-2024 |
Matthew Devereau <matthew.devereau@arm.com> |
Enable logf128 constant folding for hosts with 128bit floats (#96287)
Hosts which support a float size of 128 bits can benefit from constant
fp128 folding.
|
Revision tags: llvmorg-19.1.0-rc2 |
|
#
abc2fe31 |
| 30-Jul-2024 |
Alexander Pivovarov <pivovaa@amazon.com> |
[APFloat] Add support for f8E3M4 IEEE 754 type (#99698)
This PR adds `f8E4M3` type to APFloat.
`f8E3M4` type follows IEEE 754 convention
```c
f8E3M4 (IEEE 754)
- Exponent bias: 3
- Maximum
[APFloat] Add support for f8E3M4 IEEE 754 type (#99698)
This PR adds `f8E4M3` type to APFloat.
`f8E3M4` type follows IEEE 754 convention
```c
f8E3M4 (IEEE 754)
- Exponent bias: 3
- Maximum stored exponent value: 6 (binary 110)
- Maximum unbiased exponent value: 6 - 3 = 3
- Minimum stored exponent value: 1 (binary 001)
- Minimum unbiased exponent value: 1 − 3 = −2
- Precision specifies the total number of bits used for the significand (mantissa),
including implicit leading integer bit = 4 + 1 = 5
- Follows IEEE 754 conventions for representation of special values
- Has Positive and Negative zero
- Has Positive and Negative infinity
- Has NaNs
Additional details:
- Max exp (unbiased): 3
- Min exp (unbiased): -2
- Infinities (+/-): S.111.0000
- Zeros (+/-): S.000.0000
- NaNs: S.111.{0,1}⁴ except S.111.0000
- Max normal number: S.110.1111 = +/-2^(6-3) x (1 + 15/16) = +/-2^3 x 31 x 2^(-4) = +/-15.5
- Min normal number: S.001.0000 = +/-2^(1-3) x (1 + 0) = +/-2^(-2)
- Max subnormal number: S.000.1111 = +/-2^(-2) x 15/16 = +/-2^(-2) x 15 x 2^(-4) = +/-15 x 2^(-6)
- Min subnormal number: S.000.0001 = +/-2^(-2) x 1/16 = +/-2^(-2) x 2^(-4) = +/-2^(-6)
```
Related PRs:
- [PR-97179](https://github.com/llvm/llvm-project/pull/97179) [APFloat]
Add support for f8E4M3 IEEE 754 type
show more ...
|
Revision tags: llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
f3633177 |
| 18-Jul-2024 |
Alexander Pivovarov <pivovaa@amazon.com> |
[APFloat] Add support for f8E4M3 IEEE 754 type (#97179)
This PR adds `f8E4M3` type to APFloat.
`f8E4M3` type follows IEEE 754 convention
```c
f8E4M3 (IEEE 754)
- Exponent bias: 7
- Maximum
[APFloat] Add support for f8E4M3 IEEE 754 type (#97179)
This PR adds `f8E4M3` type to APFloat.
`f8E4M3` type follows IEEE 754 convention
```c
f8E4M3 (IEEE 754)
- Exponent bias: 7
- Maximum stored exponent value: 14 (binary 1110)
- Maximum unbiased exponent value: 14 - 7 = 7
- Minimum stored exponent value: 1 (binary 0001)
- Minimum unbiased exponent value: 1 − 7 = −6
- Precision specifies the total number of bits used for the significand (mantisa),
including implicit leading integer bit = 3 + 1 = 4
- Follows IEEE 754 conventions for representation of special values
- Has Positive and Negative zero
- Has Positive and Negative infinity
- Has NaNs
Additional details:
- Max exp (unbiased): 7
- Min exp (unbiased): -6
- Infinities (+/-): S.1111.000
- Zeros (+/-): S.0000.000
- NaNs: S.1111.{001, 010, 011, 100, 101, 110, 111}
- Max normal number: S.1110.111 = +/-2^(7) x (1 + 0.875) = +/-240
- Min normal number: S.0001.000 = +/-2^(-6)
- Max subnormal number: S.0000.111 = +/-2^(-6) x 0.875 = +/-2^(-9) x 7
- Min subnormal number: S.0000.001 = +/-2^(-6) x 0.125 = +/-2^(-9)
```
Related PRs:
- [PR-97118](https://github.com/llvm/llvm-project/pull/97118) Add f8E4M3
IEEE 754 type to mlir
show more ...
|
#
bbc6504b |
| 04-Jul-2024 |
Ariel-Burton <arielburton@yahoo.com> |
[NFC] [APFloat] Refactor IEEEFloat::toString (#97117)
This PR lifts the body of IEEEFloat::toString out to a standalone
function. We do this to facilitate code sharing with other floating
point ty
[NFC] [APFloat] Refactor IEEEFloat::toString (#97117)
This PR lifts the body of IEEEFloat::toString out to a standalone
function. We do this to facilitate code sharing with other floating
point types, e.g., the forthcoming support for HexFloat.
There is no change in functionality.
show more ...
|
#
2628a5fd |
| 29-Jun-2024 |
Alexander Pivovarov <pivovaa@amazon.com> |
Rename f8E4M3 to f8E4M3FN in mlir.extras.types py package (#97102)
Currently `f8E4M3` is mapped to `Float8E4M3FNType`.
This PR renames `f8E4M3` to `f8E4M3FN` to accurately reflect the actual
typ
Rename f8E4M3 to f8E4M3FN in mlir.extras.types py package (#97102)
Currently `f8E4M3` is mapped to `Float8E4M3FNType`.
This PR renames `f8E4M3` to `f8E4M3FN` to accurately reflect the actual
type.
This PR is needed to avoid names conflict in upcoming PR which will add
IEEE 754 `Float8E4M3Type`.
https://github.com/llvm/llvm-project/pull/97118 Add f8E4M3 IEEE 754 type
Maksim, can you review this PR? @makslevental ?
show more ...
|
Revision tags: llvmorg-18.1.8 |
|
#
880d3703 |
| 14-Jun-2024 |
Durgadoss R <durgadossr@nvidia.com> |
[APFloat] Add APFloat support for FP4 data type (#95392)
This patch adds APFloat type support for the E2M1
FP4 datatype. The definitions for this format are
detailed in section 5.3.3 of the OCP sp
[APFloat] Add APFloat support for FP4 data type (#95392)
This patch adds APFloat type support for the E2M1
FP4 datatype. The definitions for this format are
detailed in section 5.3.3 of the OCP specification,
which can be accessed here:
https://www.opencompute.org/documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf
Signed-off-by: Durgadoss R <durgadossr@nvidia.com>
show more ...
|
#
b1fe03f0 |
| 11-Jun-2024 |
Durgadoss R <durgadossr@nvidia.com> |
[APFloat] Add APFloat support for FP6 data types (#94735)
This patch adds APFloat type support for two FP6 data types,
E2M3 and E3M2. The definitions for the two formats are detailed
in section 5.
[APFloat] Add APFloat support for FP6 data types (#94735)
This patch adds APFloat type support for two FP6 data types,
E2M3 and E3M2. The definitions for the two formats are detailed
in section 5.3.2 of the OCP specification, which can be accessed here:
https://www.opencompute.org/documents/ocp-microscaling-formats-mx-v1-0-spec-final-pdf
Signed-off-by: Durgadoss R <durgadossr@nvidia.com>
show more ...
|
Revision tags: llvmorg-18.1.7 |
|
#
3613b268 |
| 29-May-2024 |
Matthew Devereau <matthew.devereau@arm.com> |
Constant Fold logf128 calls (#90611)
This is a second attempt to land #84501 which failed on several targets.
This patch adds the HAS_IEE754_FLOAT128 define which makes the check for
typedef'ing
Constant Fold logf128 calls (#90611)
This is a second attempt to land #84501 which failed on several targets.
This patch adds the HAS_IEE754_FLOAT128 define which makes the check for
typedef'ing float128 more precise by checking whether __uint128_t is
available and checking if the host does not use __ibm128 which is
prevalent on power pc targets and replaces IEEE754 float128s.
show more ...
|
Revision tags: llvmorg-18.1.6 |
|
#
595de12f |
| 14-May-2024 |
Nikita Popov <npopov@redhat.com> |
[APFloat] Replace partsCount array with single variable (NFC) (#91910)
We only ever use the last element of this array, so there shouldn't be a
need to store the preceding elements as well.
|
#
7ee62883 |
| 04-May-2024 |
Kazu Hirata <kazu@google.com> |
[Support] Use StringRef::operator== instead of StringRef::equals (NFC) (#91042)
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator== outnumbers Str
[Support] Use StringRef::operator== instead of StringRef::equals (NFC) (#91042)
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator== outnumbers StringRef::equals by a factor of 25
under llvm/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
show more ...
|