The only value that can produce -0 is exactly -0, no rounding is involved. If the
denormal mode has flushed denormal inputs, a negative value could produce -0.
The constrained intrinsics do not track the denormal mode, and this is just
generally broken in the current set of FP predicates. The move to computeKnownFPClass
will address some of these issues.
Details
Diff Detail
Event Timeline
LGTM.
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3809 | Is this FIXME useful? How could denormal handling change this behavior? |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3809 | If you have preserve-sign inputs, another negative denormal could be implicitly treated as -0 and return -0. This is fixed in the new computeKnownFPClass implementation |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3809 | In this case CannotBeNegativeZero(Call->getArgOperand(0)...) returns false and logic of this code remains valid, no? |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
3809 | No, because the current CannotBeNegativeZero doesn't consider the denormal mode at all. |
Is this FIXME useful? How could denormal handling change this behavior?