[PATCH] D71742: Added intrinsics for access to FP environment
Serge Pavlov via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Mon Dec 23 08:48:22 PST 2019
sepavloff added a comment.
In D71742#1794901 <https://reviews.llvm.org/D71742#1794901>, @kpn wrote:
> In D71742#1794638 <https://reviews.llvm.org/D71742#1794638>, @sepavloff wrote:
>
> > In D71742#1793243 <https://reviews.llvm.org/D71742#1793243>, @kpn wrote:
> >
> > > I don't see the need. Changing the FP environment in a mixed environment program is the responsibility of the programmer, and standard calls already exist for this.
> >
> >
> > This is about inlining. In the code like this:
> >
> > double f1(double x, double y) {
> > return x + y;
> > }
> > double f2(double x, double y) {
> > #pragma STDC FENV_ACCESS ON
> > ...
> > return f1(x, y);
> > }
> >
> >
> > compiler might inline call to `f1` in `f2`. However the inlined function `f1` expects default FP environment but is called in some other one.
>
>
> Nothing here changes my statement. The compiler does _not_ change the FP environment because of the #pragma. So f1() here would behave the same whether it was inlined or not.
When `f1` is defined, no pragma is in act, so its body is executed in default FP environment. `f2` contains `#pragma`, so FP environment in its body may differ from the default. When `f1` is inlined into `f2`, the body of `f1` becomes a part of the body of `f2`. Basic blocks of `f1` would be executed in the environment, set in `f2`. To keep semantics of `f1` we must execute its BBs in the default environment.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D71742/new/
https://reviews.llvm.org/D71742
More information about the llvm-commits
mailing list