[clang] [llvm] [mlir] [IR] Make semantics of strictfp consistent v2 (PR #211769)

[Ramkumar Ramachandra via llvm-commits]

================
@@ -2800,7 +2800,8 @@ fn -> other_fn -> other_fn ; fn is norecurse
     optimizations that require assumptions about the floating-point rounding
     mode or that might alter the state of floating-point status flags that
     might otherwise be set or cleared by calling this function. LLVM will
-    not introduce any new floating-point instructions that may trap.
+    not introduce any new floating-point instructions that may trap. All
+    function definitions that contain strictfp calls must be marked strictfp.
----------------
artagnon wrote:

Ah, I see. Can you explain the reasoning for the special-casing constrained FP intrinsics? Isn't strictfp an FP environment that frontends can activate using something like `#pragma STDC FENV_ACCESS ON`? If so, there are two choices:

1. The environment is turned on in the caller function, and we convert all applicable FP intrinsics to their constrained variants in Clang, and give them to LLVM. In this case, Clang's Builder has an inherent strictfp state that's flipped on, and everything it will emit is strictfp, including non-intrinsic calls. Yes, strictfp calls inhibit inlining, as it would lead to an incorrect optimization?
2. The environment is turned off in the caller function, and Clang's Builder has the strictfp state turned off, which means that we will never create constrained variants or strictfp non-intrinsic calls. Sure, it can be turned on in a non-intrinsic callee function, but the caller itself is unaffected, and non-intrinsic callees can still be inlined in the caller?

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