[llvm] [FPEnv] Add strictfp attribute to the FP environment manipulation intrinsics (PR #96093)

[Serge Pavlov via llvm-commits]

spavloff wrote:

> Wouldn't retrieving the rounding mode count as "accessing the floating-point environment"? Granted, this isn't checking the status flags and can be done in the default environment, true, but this still feels like lawyering too close to the specification.

It is not about formal things only. Setting strictfp of an operation means that it has a side effect and requests that all other operations expose their side effects too. All FP operations becomes strictly ordered and that limits optimizations. It results in performance drop, sometimes substantial. So setting strictfp should be made only when this is really needed.

> And the C standard isn't authoritative with regards to IR semantics so long as the IR semantics enable adhering to the C standard. So, while we can't ignore the C standard, the C standard isn't definitive when it comes to LLVM's IR.

Agree. But IR semantics must be flexible enough to represent semantics of C as well as Fortran, Rust and many MLIR-based languages. It is also a low-level representation, so it does not need restrictions proposed for users of high-level languages. But it should provide maximal performance.

> I'd love to hear from a backend person. Does or should any backend require the strictfp attribute on a call to retrieve the rounding mode or any of the other FP environment state that isn't a "status flag"?

Just a note. Machine representation has more flexible mechanism than strictfp. It can express the FP environment dependencies using register def-use. Many backends (including X86 and AArch64 at least) sets FP control register as implicit operand always, whether the function has strictfp attribute or not.

> If a call to get_rounding() is done in a function that isn't marked strictfp, and doesn't have the strictfp attribute at the call site, then doesn't that imply that since we're in the default FP environment we can just constant fold the call? We already assume we're in the default FP environment normally already.

`get_rounding` is proposed to read the FP control register. Making it to return an expected value instead of actual does not seem a good decision, Anyway, this is a compiler intrinsic used by compiler and library developers. They need more flexibility than artificial restrictions.


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