Details
Diff Detail
Event Timeline
I feel like there are undocumented assumptions here.
Does fptrunc +/- 0.0 preserve sign?
Is Known.SignBit supposed to be accurate even for Nans? That seems unfortunate, since for a lot of operations you won't be able to propagate it unless you can prove something isn't Nan.
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
4082 | Writing this as KnownSrc.isKnownNot(NegExcept0) would make it clearer that the source and result classes are the same here. Also why can't this logic be mirrored for PosExcept0? |
Yes
Is Known.SignBit supposed to be accurate even for Nans? That seems unfortunate, since for a lot of operations you won't be able to propagate it unless you can prove something isn't Nan.
That’s the only reason you need it. Otherwise you can infer from the mask. I only expect it to be useful for the few signbit operations
llvm/lib/Analysis/ValueTracking.cpp | ||
---|---|---|
4082 | It could be but it’s more cases to test and less useful |
Is Known.SignBit supposed to be accurate even for Nans? That seems unfortunate, since for a lot of operations you won't be able to propagate it unless you can prove something isn't Nan.
That’s the only reason you need it. Otherwise you can infer from the mask.
Ack. Could do with an explanatory note on the definition of SignBit.
But there's something odd here: the case in which you set SignBit in this patch is exactly the case in which you don't really need to because it could be inferred from the mask.
To put it another way, the information provided by SignBit overlaps with the mask, and each could be used to refine the other. Maybe the internal representation of KnownFPClass should be more orthogonal - you could have just a mask, but with separate bits for PosSNan NegSNan PosQNan NegQNan.
Writing this as KnownSrc.isKnownNot(NegExcept0) would make it clearer that the source and result classes are the same here.
Also why can't this logic be mirrored for PosExcept0?