[PATCH] D139785: [InstCombine] preserve signbit semantics of NAN with fold to fabs

[Sanjay Patel via Phabricator via llvm-commits]

spatel added a comment.

In D139785#3987049 <https://reviews.llvm.org/D139785#3987049>, @RalfJung wrote:

> Note that semantics of fneg/fabs is irrelevant for this optimization to be a problem. That's why I keep using  `float Y = true ? X1 : X2;` as the example. To my knowledge nobody disputes that `NaN < 0.0` must deterministically return false, so `X < 0.0 ? -X : X` will behave the same as `false ? -X : X` when `X` is a NAN, which is the same as just `X` -- I hope this much is uncontroversial. The only potential question then is whether `float Y = X` must preserve the NAN sign bit of `X`.
>
>   float X = /* NaN with sign bit set */;
>   float Y1 = X < 0.0 ? -X : X; // just a convoluted way to write `Y1 = false ? ... : X`, aka `Y1 = X`.
>   float Y2 = X;
>   // Clearly Y1 and Y2 must be bit-equal here, since both are just copies of X?

I think there's still some ambiguity in this example. How was X initialized/observed with -NaN? Testing for bit-equality requires casting to integer. There's no way to do that comparison with FP values?

Note that we also don't guarantee that NaN payload bits propagate. That part is less well-specified in IEEE-754, so maybe it's less controversial?

> I personally would be extremely surprised if just copying a value was allowed to alter any of its bits. Is that the alternative NAN semantics you meant, or am I misunderstanding something?

Yes, I think that's right. But as I suggested above, this is already the case and continues independently of this patch. NaN payload bits are part of this problem/discussion too, right?
https://discourse.llvm.org/t/semantics-of-nan/66729/11


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D139785/new/

https://reviews.llvm.org/D139785