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

[Ömer Sinan Ağacan via cfe-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.
----------------
osa1 wrote:

I don't think this sentence makes sense, I suggest reverting it. If you mark a function, that calls a `strictfp` function, as `strictfp`, that makes `strictfp` transitive/contagious. I.e. you'd have to mark its callers, then its callers, ... and so on. That's not how function attributes work and it's also out-of-sync with the implementation (you can call a `strictfp` function from a non-`strictfp` function).

It's also inconsistent with the "Function Attributes" section which says that the attributes are not a part the function type. If you take the pointer to a `strictfp` function you get a pointer that doesn't indicate `strictfp`. Therefore you can't even implement the semantics in this last sentence even if you wanted to.

What was the motivation for this sentence? I.e. what case did you want to make clear? @artagnon 

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