[PATCH] D69798: Implement inlining of strictfp functions

[Serge Pavlov via Phabricator via llvm-commits]

sepavloff added a comment.

In D69798#1793237 <https://reviews.llvm.org/D69798#1793237>, @kpn wrote:

> In D69798#1792906 <https://reviews.llvm.org/D69798#1792906>, @sepavloff wrote:
>
> > In D69798#1792237 <https://reviews.llvm.org/D69798#1792237>, @craig.topper wrote:
> >
> > > In D69798#1792231 <https://reviews.llvm.org/D69798#1792231>, @sepavloff wrote:
> > >
> > > > When function that uses default FP environment is inlined into strictfp function, code of the former will be executed in the FP environment set in the strictfp function. To fix this behavior the FP environment should be saved upon entry to the inlined function, FP environment reset to default state, and the saved state must be restored upon leaving the inlined function.
> > >
> > >
> > > So if the function is inlined it would use the reset state, but if it doesn't get inlined it would use the caller's state. Doesn't that mean whether or not the compiler inlines the function changes the behavior of the program?
> >
> >
> > It is so now. If a code in which `#pargma STDC FENV_ACCESS ON` acts calls an external function, it would be executed in caller's FP environment. This is wrong if the callee expects default one. We could put `get_fenv`, `reset_fenv` and `set_fenv`, introduced in D71742 <https://reviews.llvm.org/D71742>, around all calls, unless the called function has `strictfp` attribute, or we know that it does not use FP operation. It however could create unneeded code, which is bad for performance. We need to elaborate proper solution.
>
>
> If FENV_ACCESS is ON and a function is called that expects it to be OFF then isn't that just plain undefined behavior? Unless it was changed since C99 I don't see how this is the compiler's problem to solve. And the compiler really shouldn't be changing the FP environment implicitly just because an arbitrary function was called, or we fell out of an FENV_ACCESS=ON scope, or whatever.


This is a matter of convention. If it is a user responsibility to call only 'proper' functions, FP state switch is not required. It however could be a fragile solution, because in complex programs it is hard to guarantee that non of the call recursively does not imply default FP environment. The safer solution is to save/restore the environment in unclear cases, and let backend to optimize out unnecessary calls.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69798/new/

https://reviews.llvm.org/D69798