Both computeKnownBits and ComputeNumSignBits can now do a simple look-through of EXTRACT_VECTOR_ELT. It will compute the result based on the known bits (or known sign bits) for the vector that the element is extracted from.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
2460 ↗ | (On Diff #72643) | Note that this isn't as good as it could be - computeKnownBits for a vector returns the "lowest common denominator" for all vector elements. If you know, statically, which element you're looking for, you could, in theory, do better. |
2741 ↗ | (On Diff #72643) | I'm a bit surprised that ComputeNumSignBits does the right thing for vectors. In fact, I have a creeping suspicion it doesn't. |
lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
2460 ↗ | (On Diff #72643) | FYI I looked into this when I added the BUILD_VECTOR support but was put off by the size of the refactor necessary for a full per-element result. A simpler option I've considered was to add a demanded elts argument - it still wouldn't return a per-element result but at least would be only the "lowest common denominator" of the elements we actually care about. But anyway, just a TODO for this patch makes sense. |
2741 ↗ | (On Diff #72643) | ComputeNumSignBits is being used in a few places with vector types already, not sure how well its tested but the x86 SITOFP i64->FP to i32->FP transform is using it successfully. |
lib/CodeGen/SelectionDAG/SelectionDAG.cpp | ||
---|---|---|
2460 ↗ | (On Diff #72643) | The TODO has been added. Generally I guess BUILD_VECTOR could be more complicated to handle. But for EXTRACT_VECTOR_ELT we could add one argument (in all the recursive calls) telling which element we are looking for. I've not really looked into how messy such a solution would be. |
2741 ↗ | (On Diff #72643) | As Simon says, this method is used with vector types already. So I suspected that it did support vector types, and that there would be tests implemented already to verify that functionality ;-) My patch only makes it possible for an "automatic" transition from scalar->vector type during the recursion. It does not change the fact that this method can be called for any SDValue. If you suspect that it is doing something wrong for vectors, could you be more specific? By the way, the test I added ( test/CodeGen/SPARC/vector-extract-elt.ll ) is using ComputeKnownSignBits. But I think that it is a little bit annoying to depend on a target specific optimization to test these common helper functions in SelectionDAG. So is anyone has a tip on how to test these things using a different approach, please let me know. |
The reason for my skepticism w.r.t ComputeNumSignBits was that it didn't seem to explicitly handle BUILD_VECTOR (or VSELECT, vector_shuffle, etc) explicitly.
But I guess that just gets handled through computeKnownBits.
Regarding testing - unfortunately, I don't believe there's a better way to do this right now.
LGTM.
I really appreciate that you want to help out, but I think it would be nice to see that my team can commit something that has passed review ourselves.
There is currently only one person in my team that has commit permissions, and he has been busy with other things.
But the plan is to commit both this one and my similar change in ValueTracking ( https://reviews.llvm.org/D24955 ) tomorrow.
(I've also requested permission from @lattner to be able to do commits myself... we'll have to wait and see if I'm trusted...)