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

[Andy Kaylor via Phabricator via llvm-commits]

andrew.w.kaylor added a comment.

I feel like it might be a bad idea to have floating point instructions that don't have constrained forms.

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?

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.

If we don't introduce a first class fneg instruction, I don't think we can rely on the CodeGen always pattern matching -0-X to an fneg instruction. The fact that it does that is nice, but if there is nothing requiring it to happen we should assume that it won't always happen.

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.


Repository:
  rL LLVM

https://reviews.llvm.org/D50913