[PATCH] D69798: Implement inlining of strictfp functions

Serge Pavlov via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 20 08:29:27 PST 2019


sepavloff added a comment.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69798





More information about the llvm-commits mailing list