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

Ulrich Weigand via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Dec 23 09:06:41 PST 2019


uweigand added a comment.

In D71742#1795014 <https://reviews.llvm.org/D71742#1795014>, @craig.topper wrote:

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


Exactly.   It is the responsibility of the **programmer** to ensure f1 is being called with the correct environment set.   C11 7.6.1.2 explicitly says:

> If part of a program [...] runs under non-default mode settings, but was translated with the state for the FENV_ACCESS pragma ‘‘off’’, the behavior is undefined.

The only issue for the compiler w.r.t. inlining is the case where the programmer writes correct code in f2, i.e. resets the environment to the default state before calling f1, but then f1 is inlined into f2.  In this scenario, the compiler must ensure to **preserve** correctness by not scheduling any part of the inlined f1 to before the instruction in f2 that resets the environment.  This can be achieved e.g. by the inliner replacing all regular FP instructions with constrained intrinsics (which may specify the default mode).


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