Details
Diff Detail
Event Timeline
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
4222 | This is discarding anything we already knew. The docs should make that clear (for this function and propagateCanonicalizingSrc) - or change it so it only &s new information into KnownFPClasses. |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
4239 | I think this needs to be fcZero for correctness, because a negative subnormal could be flushed to +0. (I guess this is what the TODO alludes to, but (a) it should be a FIXME and (b) maybe just do it?) | |
4829–4830 | Typo for "non-zero"? But in any case I'm not sure what the comment means or how it relates to this part of the code. Non-zeroness of the input won't be preserved if exp is negative - a non-zero input could easily underflow to a zero result. | |
4840 | ||
4849 | This should have been simplified already to an explicit canonicalize, right? |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
4829–4830 | The point was this is a slightly stronger version of the previous block checking cannotBeOrdered{Less|Greater}ThanZero that covers 0. The sign isn't changing regardless of overflow | |
4840 | This regresses a few cases. The independent +/- pieces can be inferred below | |
4849 | No, non-constrained operations aren't guaranteed to canonicalize. Nothing folds to canonicalize. This should have folded to a direct x reference. We aren't reporting that the result is canonical, it's reporting that it could have been flushed. The simplification for this also checks for a literal 0, this query is the full known class query. Theoretically a case could exist that's known 0 but isn't a constant 0 |
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
4238 | Only do this if the input or output mode is preserve-sign or dynamic? |
Rebase to pick this up from trunk