[PATCH] D139316: ValueTracking: Teach isKnownNeverInfinity about rounding intrinsics
Serge Pavlov via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Dec 9 10:38:42 PST 2022
sepavloff added a comment.
In D139316#3984809 <https://reviews.llvm.org/D139316#3984809>, @arsenm wrote:
> In D139316#3982777 <https://reviews.llvm.org/D139316#3982777>, @jcranmer-intel wrote:
>
>> In D139316#3981280 <https://reviews.llvm.org/D139316#3981280>, @kpn wrote:
>>
>>> Are we certain that a value that is very close to infinity won't trip over into infinity after rounding?
>>
>> I'm thinking it might not be true for ppc_fp128--{largest_finite64, 0.75} should round into infinity I think? All of the other IEEE-like floating point types should have it be true, though--even e4m3 and e5m2 have largest_finite be an integer.
>
> What should I do here? How do I check this? godbolt seems to not support ppc execution, and I've had a real hard time finding any ppc f128 documentation
PPC uses double double encoding (https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format), in which a number is represented by a sum of two double precision numbers, where the second just keeps additional mantissa bits. Total number of mantissa bits in ppc_fp128 is about 107 bits. Exponent range is the same as for double numbers: 2^-1022 to 2^1023. So large numbers (above 2^108) are always integers, they do not need rounding and the result of ceil, floor etc is the argument.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D139316/new/
https://reviews.llvm.org/D139316
More information about the llvm-commits
mailing list