[PATCH] D71742: Added intrinsics for access to FP environment

[Craig Topper via Phabricator via llvm-commits]

craig.topper added a comment.

In D71742#1795013 <https://reviews.llvm.org/D71742#1795013>, @sepavloff wrote:

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


I don’t see how inlining is any different than f2 calling f1 without it being inlined. f1 would execute with the f2 environment in that case too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71742