kpneal wrote: A recap of the history of the strictfp attribute.
Originally we needed a way to prevent the Inliner from inlining a non-strictfp function into a strictfp function. We added the `strictfp` attribute to the function definition for this. Then we found that basic blocks were being optimized when they didn't belong to a function so we couldn't get to the where the `strictfp `attribute was located. The solution was to add the attribute to every function call. Simple. Then I went to work on the Verifier changes. Originally I implemented it by checking to see if the presence of the attribute on a call site matched the presence on the function definition. Easy. But then I ran into a problem: Checks at call sites to see if an attribute is present will look through to the function declaration. Thus, we had to weaken the rule. Now, the `strictfp` attribute is allowed at call sites when the attribute is missing from the calling function's definition. If the `strictfp` attribute is present on the calling function's definition then the strictfp attribute is required on all call sites. This is the rule that is present in my IR Verifier ticket that was [approved (D146845)](https://reviews.llvm.org/D146845?id=542509) but not pushed because we still have broken tests. 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? 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'm not convinced we're ready to drop any uses of the `strictfp` attribute without having all places that check for it changed first. And, does it make sense for the Inliner to be unable to inline a function if the called function `onlyAccessesInaccessibleMem()`? I don't think we're ready for a switchover. 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
