[KnownFPClass] Infer that the inverse square root `1.0 / sqrt(x)` cannot be positive subnormal
- Dominant language
- LLVM
- Stars
- 40.5k
- Forks
- 18.7k
- PR merge metrics
- PR metrics pending
Description
The result from `1.0 / sqrt(x)` can only ever be `-Inf`, `+0.0`, `positive-normal`, `+Inf`, or `NaN`.
In its current form, `KnownFPClass` has no way to determine that `1.0 / sqrt(x)` will never produce a positive subnormal without passing in range/magnitude/exponent information from `sqrt(x)`. Since in general, `normal / normal` can become subnormal.
Possible solutions:
- Add a `rsqrt` intrinsic (may be tricky due to rounding differences)
- Special case `1.0 / sqrt(x)`
- Special case `constant / x` (and maybe `x / constant`) similar to the special case for `x * constant`
***
Background:
Currently, `KnownFPClass` is not able to rule out any FP classes for `1.0 / sqrt(x)` for the general case. For the case where `x` is not negative zero, `KnownFPClass` can deduce that `1.0 / sqrt(x)` is not negative normal nor negative subnormal.
This patch https://github.com/llvm/llvm-project/pull/214912 allows `KnownFPClass` to deduce that `1.0 / sqrt(x)` is not negative normal nor negative subnormal in the general case.
`fdiv` can be further refined to handle the case where `1.0 / sqrt(x)` will never produce negative zero.
Contributor guide
Research direction
Start by reading the KnownFPClass handling for fdiv and sqrt, then review PR 214912 for the existing negative-class refinement. Compare the proposed rsqrt, 1.0 / sqrt(x), and constant-division approaches. Done means KnownFPClass can rule out positive subnormal results for this expression without incorrect rounding assumptions.
Written by the indexing model from the issue text.
Assessment
- Domain
- compilers
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100