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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to