[PATCH] D28928: [ValueTracking] Implement SignBitMustBeZero correctly for sqrt.

[Justin Lebar via Phabricator via llvm-commits]

jlebar added a comment.

> ! In https://reviews.llvm.org/D28928#656636, @efriedma wrote:
>  The weird edge-case is where you have an nsz instruction which feeds into a non-nsz instruction: either we restrict optimization like you describe, or users of an nsz instruction are effectively nsz themselves.

Agreed, these are the two options.  But I would amend the second option to say that the users of these instructions are "halfway nsz" themselves.  Their inputs are nsz, but their outputs are not.

> The latter seems worse... for example, if we started using SignBitMustBeZero to feed into integer KnownBits computations, we could have an integer value 0x80000000 whose top bit is "known" to be zero, which would lead to undefined behavior.

Are you worried about the case where we have something like

  float f = nsz some_op;
  int i = bitcast f to int
  bool b = top bit of i

?  I think as soon as we leave the fp space we can no longer play fast and loose with signed zeroes.  Like, the result of the bitcast must have some value for its sign bit -- doesn't matter what it is because nsz -- and then we must stick with that, consistently.

>> If x == -0, for example, can if (x != -0) print(x); print -0?
> 
> No, because `0. == -0.` is true. :)

Not sure if kidding around; if not, I think Hal was trying to ask: Can`if (x == 0 && !signbit(x)) print (x);` print "-0"?  He's saying yes (if the whole program is compiled with nsz), and I think I agree.


https://reviews.llvm.org/D28928