In C++17, static constexpr members are implicitly inline, so they no longer require an out-of-line definition. Identified with readability-redundant-declaration.
We have: /// Once all uses of this constructor are migrated to other constructors, /// consider marking this overload ""= delete" to prevent calls from being /// incorrectly bound to the APInt(unsigned, uint64_t, bool) constructor. LLVM_ABI APInt(unsigned numBits, unsigned numWords, const uint64_t bigVal[]); This patch migrates away from this soft-deprecated constructor.
As discussed in https://github.com/llvm/llvm-project/pull/111544#issuecomment-3405281695, large special member functions in APFloat prevent function inlining and cause compile-time regression. This patch moves them into the cpp file. Compile-time improvement (-0.1%): https://llvm-compile-time-tracker.com/compare.php?from=0f68dc6cffd93954188f73bff8aced93aab63687&to=d3105c0860920651a7e939346e67c040776b2278&stat=instructions:u
This patch exposes the declaration of fltSemantics to inline PPCDoubleDouble() calls in the IEEEFloat/DoubleAPFloat dispatch. It slightly improves the compile time: https://llvm-compile-time-tracker.com/compare.php?from=f4359301c033694d36865c7560714164d2050240&to=68de94d77d5bd33603193e8769829345b18fbae3&stat=instructions:u With https://github.com/llvm/llvm-project/pull/111544, the improvement is more significant: https://llvm-compile-time-tracker.com/compare.php?from=e438bae71d1fd55640d942b9ad795de2f60e44f2&to=04751477940890c092dc4edb74e284de8f746d5a&stat=instructions:u Address comment https://github.com/llvm/llvm-project/pull/111544#issuecomment-3405281695. If breaking changes are allowed, we can encode all the properties of fltSemantics within a 64-bit integer. Then we don't need `Semantics <-> const fltSemantic` conversion.
Without this patch, we call APFloat::makeQuiet() in frexp like so: Quiet.getFirst().makeQuiet(); The problem is that makeQuiet returns a new value instead of modifying "*this" in place, so we end up discarding the newly returned value. This patch fixes the problem by assigning the result back to Quiet.getFirst(). We should put [[nodiscard]] on APFloat::makeQuiet, but I'll do that in another patch.
The old implementation converted to the legacy semantics, inducing rounding and not properly handling inputs like (2^1000 + 2^200) which have have more precision than the legacy semantics can represent. Instead, we convert the integer into two floats and an error. The error is used to implement the rounding behavior. Remove related dead, untested code: convertFrom*ExtendedInteger
The prior implementation would treat X+Y and X-Y as having equal magnitude. Rework the implementation to be more resilient.
The previous implementation of getExactInverse used the following check
to identify powers of two:
// Check that the number is a power of two by making sure that only the
// integer bit is set in the significand.
if (significandLSB() != semantics->precision - 1)
return false;
This condition verifies that the only set bit in the significand is the
integer bit, which is correct for normal numbers. However, this logic is
not correct for subnormal values.
APFloat represents subnormal numbers by shifting the significand right
while holding the exponent at its minimum value. For a power of two in
the subnormal range, its single set bit will therefore be at a position
lower than precision - 1. The original check would consequently fail,
causing the function to determine that these numbers do not have an
exact multiplicative inverse.
The new logic calculated this correctly but it seems that
test/CodeGen/Thumb2/mve-vcvt-fixed-to-float.ll expected the old
behavior.
Seeing as how getExactInverse does not have tests or documentation, we
conservatively maintain (and document) this behavior.
This reverts commit 47e62e846beb267aad50eb9195dfd855e160483e.
This reverts commit f4941319cba19d7691baa6ec783c84be4d847637. This broke llvm/test/CodeGen/Thumb2/mve-vcvt-fixed-to-float.ll which took out a ton of buildbots and also broke premerge.