llvm-project.git/llvm/lib/Support/APFloat.cpp, branch users/nico/python-1 Unnamed repository; edit this file 'description' to name the repository. [NFC][ADT/Support] Add {} for else when if body has {} (#140758) 2025-05-21T20:19:09+00:00 Rahul Joshi rjoshi@nvidia.com 2025-05-21T20:19:09+00:00 a76bf4da53182baace54fd69f9d38fc10e6b8e85 






[llvm] Use StringRef::consume_front (NFC) (#139458)
2025-05-11T17:28:49+00:00

Kazu Hirata
kazu@google.com

2025-05-11T17:28:49+00:00

7470131b43405a07ccafd83aea286d0f35aefb34












[InstCombine] Fold fneg/fabs patterns with ppc_f128 (#130557)
2025-04-14T06:30:00+00:00

Yingwei Zheng
dtcxzyw2333@gmail.com

2025-04-14T06:30:00+00:00

e710a5a9f274162c63e32aa8d88f6a734759b4a5

This patch is needed by
https://github.com/llvm/llvm-project/pull/130496.




This patch is needed by
https://github.com/llvm/llvm-project/pull/130496.






[APFloat] Fix `IEEEFloat::addOrSubtractSignificand` and `IEEEFloat::normalize` (#98721)
2025-03-10T02:44:27+00:00

beetrees
b@beetr.ee

2025-03-10T02:44:27+00:00

8b9c91ec7da0ca3daab8ff6711126443e500bb66

Fixes #63895
Fixes #104984

Before this PR, `addOrSubtractSignificand` presumed that the loss came
from the side being subtracted, and didn't handle the case where lhs ==
rhs and there was loss. This can occur during FMA. This PR fixes the
situation by correctly determining where the loss came from and handling
it appropriately.

Additionally, `normalize` failed to adjust the exponent when the
significand is zero but `lost_fraction != lfExactlyZero`. This meant
that the test case from #63895 was rounded incorrectly as the loss
wasn't adjusted to account for the exponent being below the minimum
exponent. This PR fixes this by only skipping the exponent adjustment if
the significand is zero and there was no lost fraction.

(Note to reviewer: I don't have commit access)




Fixes #63895
Fixes #104984

Before this PR, `addOrSubtractSignificand` presumed that the loss came
from the side being subtracted, and didn't handle the case where lhs ==
rhs and there was loss. This can occur during FMA. This PR fixes the
situation by correctly determining where the loss came from and handling
it appropriately.

Additionally, `normalize` failed to adjust the exponent when the
significand is zero but `lost_fraction != lfExactlyZero`. This meant
that the test case from #63895 was rounded incorrectly as the loss
wasn't adjusted to account for the exponent being below the minimum
exponent. This PR fixes this by only skipping the exponent adjustment if
the significand is zero and there was no lost fraction.

(Note to reviewer: I don't have commit access)






ADT: Switch to a raw pointer for DoubleAPFloat::Floats.
2025-03-06T05:15:08+00:00

Peter Collingbourne
pcc@google.com

2025-03-06T05:15:08+00:00

c72ebeeb7f1cebb481243cce3a5b18f548a9d930

In order for the union APFloat::Storage to permit access to the
semantics field when another union member is stored there, all members
of Storage must be standard layout. This is not necessarily the case
for DoubleAPFloat which may be non-standard layout because there is no
requirement that its std::unique_ptr member is standard layout. Fix this
by converting Floats to a raw pointer.

Reviewers: arsenm

Reviewed By: arsenm

Pull Request: https://github.com/llvm/llvm-project/pull/129981





In order for the union APFloat::Storage to permit access to the
semantics field when another union member is stored there, all members
of Storage must be standard layout. This is not necessarily the case
for DoubleAPFloat which may be non-standard layout because there is no
requirement that its std::unique_ptr member is standard layout. Fix this
by converting Floats to a raw pointer.

Reviewers: arsenm

Reviewed By: arsenm

Pull Request: https://github.com/llvm/llvm-project/pull/129981







[X86][DAGCombiner] Skip x87 fp80 values in `combineFMulOrFDivWithIntPow2` (#128618)
2025-02-25T14:03:17+00:00

Yingwei Zheng
dtcxzyw2333@gmail.com

2025-02-25T14:03:17+00:00

44d1dbd24c20a0ee93063dcf44d68e2b8f0bf77c

f80 is not a valid IEEE floating-point type.
Closes https://github.com/llvm/llvm-project/issues/128528.




f80 is not a valid IEEE floating-point type.
Closes https://github.com/llvm/llvm-project/issues/128528.






[APFloat][NFC]extract `fltSemantics::isRepresentableBy` to header (#122636)
2025-01-13T22:12:04+00:00

Congcong Cai
congcongcai0907@163.com

2025-01-13T22:12:04+00:00

ad56f6267f6b208c46074d9f58464f171418d619

isRepresentableBy is useful to check float point type compatibility




isRepresentableBy is useful to check float point type compatibility






[llvm][NFC] `APFloat`: Add missing semantics to enum (#117291)
2024-12-04T22:58:59+00:00

Matthias Springer
me@m-sp.org

2024-12-04T22:58:59+00:00

f50ce316ec434f1e2f061287a48d85acde801a3d

* Add missing semantics to the `Semantics` enum.
* Move all documentation of the semantics to the header file.
* Also rename some functions for consistency.




* Add missing semantics to the `Semantics` enum.
* Move all documentation of the semantics to the header file.
* Also rename some functions for consistency.






[llvm] `APFloat`: Add helpers to query NaN/inf semantics (#116315)
2024-11-16T02:48:05+00:00

Matthias Springer
me@m-sp.org

2024-11-16T02:48:05+00:00

309c890921b8d2f33e32aac4890317b887189a1f

`APFloat` changes extracted from #116176 as per reviewer comments.




`APFloat` changes extracted from #116176 as per reviewer comments.






[llvm] `APFloat`: Query `hasNanOrInf` from semantics (#116158)
2024-11-15T00:29:54+00:00

Matthias Springer
me@m-sp.org

2024-11-15T00:29:54+00:00

2f55de4e317ee93cdca839558acf8be2b5ac2b46

Whether a floating point type supports NaN or infinity can be queried
from its semantics. No need to hard-code a list of types.




Whether a floating point type supports NaN or infinity can be queried
from its semantics. No need to hard-code a list of types.