[llvm] LangRef: state explicitly that floats generally behave according to IEEE-754 (PR #102140)

Joshua Cranmer via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 12 13:46:08 PDT 2024


jcranmer-intel wrote:

I'm broadly supportive of the idea to bring greater clarity here; I'm not entirely certain this is the best way to do it. IEEE 754 just isn't quite precise enough to say that "it's just IEEE 754 behavior!" answers the questions that people are trying to ask. Also, we have three non-IEEE 754 types: `bfloat` (whose behavior is completely describable with IEEE 754 format parameters, although I think the denormal flushing behavior is likely to be especially inconsistent here), `x86_fp80` (which is mostly describable with IEEE 754, although it also introduces noncanonical values which don't exist with the basic IEEE 754 binary formats, but are allowed for in the standard), and `ppc_fp128` (which is very pointedly not an IEEE 754 format type, and I have yet to find a document describing its semantics in any useful detail).

What I think should be explicitly mentioned are these:
- it's not legal to x87-style store the result in a larger register without truncating it back to range (and you must ensure no double-rounding occurs when emulating in a larger type); `fadd float` really does mean IEEE 754 binary32 addition (as far as rounding is concerned).
- optimizations cannot change the precision of the result unless annotated with fast-math flags

(Denormal flushing is cursed for reasons beyond the scope of this PR, and I don't think the `denormal-fp-math` is really sufficient to capture the cursed nature.)

https://github.com/llvm/llvm-project/pull/102140


More information about the llvm-commits mailing list