[llvm] [FPEnv] Add strictfp attribute to the FP environment manipulation intrinsics (PR #96093)

Kevin P. Neal via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 12 11:35:25 PDT 2024


kpneal wrote:

> > The API for checking for attributes at call sites looks through to function declarations always. It would be asking for trouble to have one attribute behave differently.
> 
> Maybe we need two attributes, one meaning "this function must be implemented using strictfp operations" and another meaning "The code that calls this function must use strictfp operations"? The latter is what strictfp means according the documentation and the former is just an information about function implementation and should not propagates to calls.

That still leaves us with an attribute that doesn't behave the same as all the other attributes. 
 
> > So the propagation both decreases the cognitive load on developers by having the attribute checks all behave the same, and it helps avoid bugs by keeping the attribute from being accidentally lost. The harm is... what?
> 
> If a function use pragma FENV_ACCESS is a small piece of code, the entire function becomes strictfp. If a function call such function it must assign strictfp attribute to such calls and according the meaning of this attribute, the caller function becomes strictfp. Consequently all callers of this function becomes strictfp and so on. The entire application becomes strictfp. It may result in substantial performance drop.

Not quite.

>From the LangRef:
>All function calls done in a function that uses constrained floating point intrinsics must have the strictfp attribute either on the calling instruction or on the declaration or definition of the function being called.
>
>All function definitions that use constrained floating point intrinsics must have the strictfp attribute.

In a function that does _not_ use the constrained intrinsics the LangRef imposes no requirement that the strictfp attribute be present on every function call, and there's no requirement that it be on the function definition either. So the assertion that a function with a call to a strictfp function must itself be strictfp is incorrect.

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


More information about the llvm-commits mailing list