[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