History log of /llvm-project/llvm/lib/Support/APFloat.cpp (Results 1 – 25 of 340)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


12345678910>>...14