We need to expand the set of possible classes to the opposite
sign for the first operand if we don't know the sign of the second
operand.
Details
Details
Diff Detail
Diff Detail
Event Timeline
llvm/include/llvm/Analysis/ValueTracking.h | ||
---|---|---|
399–402 | This doesn't work. Sign.isKnownNever(fcPositive) does not guarantee that the sign bit of Sign is 1, since it could be a nan with the sign bit clear. I guess you meant Sign.isKnownNever(fcPositive | fcNan)? But this is another case where you could test Sign.SignBit && *Sign.SignBit as well or instead, since there is redundancy in the representation. |
llvm/include/llvm/Analysis/ValueTracking.h | ||
---|---|---|
403 | How do you know the result is not nan? |
llvm/include/llvm/Analysis/ValueTracking.h | ||
---|---|---|
403 | You don’t. This is avoiding clearing the bits that say it could be nan |
This doesn't work. Sign.isKnownNever(fcPositive) does not guarantee that the sign bit of Sign is 1, since it could be a nan with the sign bit clear.
I guess you meant Sign.isKnownNever(fcPositive | fcNan)? But this is another case where you could test Sign.SignBit && *Sign.SignBit as well or instead, since there is redundancy in the representation.