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

[Cameron McInally via Phabricator via llvm-commits]

cameron.mcinally added a comment.

>> The user writes a unary minus, -x, which is a bitwise operation and will never trap.
> 
> Do we know this for certain?

Yes, this is specified by IEEE-754 Section 5.5.1 (my copy is old, but I don't believe this has changed):

"negate(x) copies a floating-point operand x to a destination in the same format, reversing the sign bit. negate(x) is not the same as subtraction(0, x) (see 6.3)."

This section also states that "The operations treat floating-point numbers and NaNs alike, and signal no exception."

> I'm sticking with my thinking that a constrained fsub instruction should never be turned into an FNEG SDNode. It's a very simple rule that won't result in confused or surprised programmers.

This is correct. We cannot optimize away a trap that existed in the original program.

> This rule also means a constrained FNEG would not be needed.

I'm not so sure about this. We may be able to do without a constrained FNEG if the FEs and LLVM agree to an implicit contract on unconstrained FSUB. But, right now, I don't think we fully comply in all cases.


Repository:
  rL LLVM

https://reviews.llvm.org/D50913