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

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

> Reading it the opposite way -- that nsz sqrt(+0) might return -0 and we have to account for this as a possibility -- would mean that nsz *limits* our optimization opportunities, which seems clearly not what it's intended to do.

Well, if everything is nsz, that doesn't really come up; the user is under the same restriction as the sqrt() itself, so it doesn't limit optimization.  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.  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.

> If x == -0, for example, can if (x != -0) print(x); print -0?

No, because `0. == -0.` is true. :)


https://reviews.llvm.org/D28928