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