[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#1285602, @cameron.mcinally wrote:

> In https://reviews.llvm.org/D43142#1285565, @kpn wrote:
>
> > If all optimizations including constant folding, or at least optimizations on floating point, are delayed until after inlining then there's no problem.
>
>
> I'll add that this is a ton of work. A binary Instruction can't currently have two Constant operands. So, ConstantFolding is baked into the Instruction implementation right now. If I'm mistaken, someone please correct me.


Surely this can be worked around with assigning to compiler temporaries?

Dealing with statics may be an issue. This was mentioned to me at lunch by our front end guy.

> I'm not an expert on inlining, but I imagine there are challenges moving it to 1st in the pass order too. I could see it being difficult to analyze cost on an unoptimized, non-canonical IR.
> 
> There are probably other optimizations, like InstCombine, that we're not considering also.

OK, that sounds like something that may get dealt with when we have time to polish things into an ideal state. Maybe never.

> If my reasoning in my last comment is correct, we don't have to worry about inlining FENV_ACCESS=OFF functions. Since it's undefined behavior, we're free to inline that function with no modifications. It's the user's responsibility to make sure that a FENV_ACCESS=OFF function isn't called by a FENV_ACCESS=ON function without explicitly modifying the FP environment.

Hmmm. A clang option to turn on FENV_ACCESS for entire compilations would work around this issue. So the behavior you are describing here would work for me.


https://reviews.llvm.org/D43142