[PATCH] D43142: Experimental pass to convert all floating point operations to the equivalent constrained intrinsics

[Kevin P. Neal via Phabricator via llvm-commits]

kpn added a comment.

In https://reviews.llvm.org/D43142#1285825, @andrew.w.kaylor wrote:

> In https://reviews.llvm.org/D43142#1285789, @cameron.mcinally wrote:
>
> > In https://reviews.llvm.org/D43142#1285708, @andrew.w.kaylor wrote:
> >
> > > The only thing we need to worry about is making sure that FP operations don't migrate across calls or other FP operations that would break these semantics. Using the intrinsics after inlining takes care of that.
> >
> >
> > I don't agree with this. This is changing the semantics if we choose to inline a function by converting some operations into constrained intrinsics. In other words, an executable will have different behavior if we choose to inline or not. That's not ok.
>
>
> Well, yes and no. In a region defined as FENV_ACCESS off the user has granted the compiler explicit permission to ignore FP status bits and exception behavior. Depending on how we optimize these regions the FP status bits may come out differently and exceptions may or may not be raised, but the user has promised not to unmask exceptions or look at status bits in that region. So if that part of the behavior of the code changes depending on whether or not we inline that's OK because that's what the user signed up for. In that sense the behavior hasn't changed any more than it does between -O0 and -O3.


More specifically, in an all FENV_ACCESS=OFF world we _already_ have different results that come from the compiler choosing to inline or not. So different results from inlining a FENV_ACCESS=OFF function into a FENV_ACCESS=ON function is just more of the same.

To the point about barriers, converting to use the constrained intrinsics functions as a barrier whether or not the =OFF function calls fpenableexcept() and friends.

> Now maybe someone might have code that calls an FENV_ACCESS OFF function from an FENV_ACCESS ON function and then looks at FP status bits after the call returns, but the standard explicitly says that when controls transfers from a scope with FENV_ACCESS off to a scope with FENV_ACCESS on the state of the FP status flags is undefined.
> 
> So, yes, technically the behavior may change, but that's OK.

Agreed.


https://reviews.llvm.org/D43142