[clang] [llvm] [IR] Don't set strictfp on irrelevant calls (PR #122735)

[Serge Pavlov via llvm-commits]

spavloff wrote:

Thank you for your retrospective view on `strictfp`. I didn't realize how much it is related to inlining. This use case should be carefully analyzed to refine meaning of the attribute.

> Clearly intrinisics don't get inlined by the Inliner. But what if an intrinsic gets lowered to a call to a real function? Especially if LTO is being used? Will we lose the information that the function now being called needs the strictfp attribute or something similar? Since we don't have a way to mark accessing the FP environment, exactly, then aren't we throwing away information?

Intrinsic function is what compiler knows a priori. It knows its effects and properties, in particular how it interacts with FP environment. If it is implemented as a call to real function (with a body) there are no problem, - an external function call has side effect and it may do anything, including access to FP environment. But if that body is inlined, things get more complicated.

- If the caller is strictfp but the callee implementation is not, the inlined body is transformed into strictfp form by replacing FP operations with their constrained variants.

- If the caller is not `strictfp` but the callee is, inlining should not take place (see the file lvm/test/Transforms/Inline/inline-strictfp.ll, test inlined_05).

- If both caller and callee are `strictfp` or both are not, this is a trivial case.

In all cases inlining does not create invalid constructs and additional information is not needed.

> Is it still possible to write a check in the Verifier to catch any places where the strictfp attribute, or some equivalent, is missing?

I think we need first to refine meaning of `strictfp`. Maybe this attribute can be used for function body only, and for call site `MemoryEffets.doesAccessesInaccessibleMem()` would be enough?



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