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

[Matt Arsenault via Phabricator via llvm-commits]

arsenm added a comment.

In https://reviews.llvm.org/D50913#1206266, @kpn wrote:

> I just got done talking to one of our floating point math guys here.
>
> In https://reviews.llvm.org/D50913#1205990, @cameron.mcinally wrote:
>
> > > If the fsub that led to the FNEG node was not constrained in the first place then this seems like a valid transform.
> >
> > Bah, sorry. My comment was ambiguous...
> >
> > I meant that the FNEG->FSUB xform is "bad" in the context Ulrich proposed. For example:
> >
> > The user writes a unary minus, -x, which is a bitwise operation and will never trap. The frontend would then convert -x to an *unconstrained* -0-x. InstCombine catches this pattern and canonicalizes the -0-x to a FNEG. But, if the target expands the FNEG, it will be converted back into an FSUB, which is arithmetic and could trap. We don't want to introduce traps where none were originally intended.
>
>
> This sounds like the case for a constrained fneg intrinsic.
>
> We can't convert -x into an fsub, constrained or not, because we can't risk introducing or removing traps. We need an unambiguous way of making a distinction between "-0-x" and "-x". The constrained fneg intrinsic would allow that distinction.


This is a problem with the representation of fneg as an fsub. We should just fix that hack with a proper fneg instruction, and eliminate the transformations to fsubs where appropriat


Repository:
  rL LLVM

https://reviews.llvm.org/D50913