[PATCH] D25007: [DAG] Teach computeKnownBits and ComputeNumSignBits in SelectionDAG to look through EXTRACT_VECTOR_ELT.

[Bjorn Pettersson via llvm-commits]

bjope added inline comments.


> RKSimon wrote in SelectionDAG.cpp:2460
> 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.

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.

> mkuper wrote in SelectionDAG.cpp:2741
> I'm a bit surprised that ComputeNumSignBits does the right thing for vectors. In fact, I have a creeping suspicion it doesn't.
> Do you have a test for that specifically?

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.

https://reviews.llvm.org/D25007