[PATCH] D50913: [FPEnv] Don't need copysign/fabs/fneg constrained intrinsics

[Cameron McInally via Phabricator via llvm-commits]

cameron.mcinally added a comment.

> For one thing, we need to not just consider the operation itself but also any possible ways it can be combined with other operations. We might be confident that fneg X can stand alone without fear of trapping, but by not making a constrained version we are implicitly giving the optimizer freedom to combine this with other operations. Can we be sure the optimizer won't find some clever way to combine a sequence of non-constrained operations that we thought didn't need constrained forms and end up with an unconstrained fadd or fsub somewhere?

I'm not sure the search space is that big for this. There are only 4 quiet-computational operations: copy, abs, neg, and copysign. Neg is the only one that we have to worry about being converted into a trapping operation. If there's a contract that an FNEG will never be converted into an FSUB, then it's fine to optimize them. In fact, we want the operations to be optimized.

> Also, we previously agreed that if any FP operations in a function required constrained intrinsics then all FP operations in that function would get constrained intrinsics. This was to avoid operations migrating across boundaries after inlining and such. If we had a function that contained an fneg that was not marked as constrained and no other constrained operations and that function was inlined into a function that was not constrained, the fneg could easily end up being combined with unconstrained fsub and fadd operations.

This sounds okay to me. If an fneg is combined with an unconstrained operation, there was no intention of trap-safety on the unconstrained operation in the first place. If the user is issuing unconstrained operations with traps enabled, that's their mistake.

That said, a fneg cannot be combined with a constrained operation freely.

> I am not against introducing a first class fneg instruction, but I do want to point out that even if we do so the lack of trapping behavior cannot be part of the definition of the instruction. Or rather that fact won't distinguish it from other FP instructions because the LLVM language reference explicitly states that all FP instructions are assumed to have no side effects. So there is no reason for the optimizer to preserve this non-trapping property in the abscence of constrained intrinsics.

Your argument here is compelling. If there's no guarantee that an FSUB and FNEG are disjoint, then this won't work. Although, an FSUB and FNEG aren't really the same operation. Perhaps we should only be doing the transformation under UnsafeMath conditions to begin with...


Repository:
  rL LLVM

https://reviews.llvm.org/D50913