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

[Cameron McInally via Phabricator via llvm-commits]

cameron.mcinally added a comment.

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.

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.

> And the optimizations applied to an inlined functions don't have to be the same as the optimizations on the standalone function. The copy of bar() inlined into main() can inherit the >FENV_ACCESS ON of main() despite the standalone version of bar() having it OFF.

At its core, this code has undefined behavior. So, your suggestion is one possible solution.

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.

Well, at least that's my current understanding of the problem. Does anyone see problems with my initial assumptions?


https://reviews.llvm.org/D43142