[PATCH] D69798: Implement inlining of strictfp functions

[Kevin P. Neal via Phabricator via llvm-commits]

kpn added a comment.

In D69798#1794639 <https://reviews.llvm.org/D69798#1794639>, @sepavloff wrote:

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




>> 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.

It _is_ the responsibility of the user to not call problematic functions. That _is_ the current convention. Yes, it may be fragile, but that's still the user's problem to solve. And the compiler can't know when the calls aren't needed because that information about functions in other TU simply isn't available. Plus, there are cases where functions are compiled with the #pragma and are expecting to be called with a non-default FP environment, but they don't change the environment themselves. So having the compiler insert calls to change the environment before calling would be an error. It's a mistake to trade off a set of potential errors caused by the programmer in exchange for a set of problems caused by the compiler.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69798