This patch adds support for expanding vector CTPOP instructions and removes the x86 'bitmath' lowering which replicates the same expansion.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp | ||
---|---|---|
1091 | It should be possible to avoid using MUL if it isn't legal. Not sure how much work that would be to fix. It's generally not a good idea to push vector legalization work to LegalizeDAG; there's a separate legalization stage for vectors precisely because LegalizeDAG can't unroll arbitrary vectors. (This is the issue you mentioned with ARM support for v2i64 multiply.) It would be better to factor out the expansion routine into a separate function, and call it from both VectorLegalizer and LegalizeDAG. |
lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp | ||
---|---|---|
1091 | Not sure we have great examples of sharing between LegalizeDAG and LegalizeVectorOps, specifically, but we have some shared lowering routines in TargetLowering.h that are used in various places. |
Updated vector CTPOP expansion to use TargetLowering::expandCTPOP.
We still have the issue with x86 bitcast'd logic operations preventing reassociation.
lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
4219 ↗ | (On Diff #171396) | It doesn't seem safe to assert that all legal integer vector types (or, more generally, all legal integer types) have size between i8 and i128. |
4226 ↗ | (On Diff #171396) | I'm sort of on the fence about whether this check should be here, or in VectorLegalizer::ExpandCTPOP. Either way works, I guess. |
lib/CodeGen/SelectionDAG/TargetLowering.cpp | ||
---|---|---|
4219 ↗ | (On Diff #171396) | This is a direct copy from the LegalizeDAG version - I can change this to an early out if you'd prefer |
4226 ↗ | (On Diff #171396) | I agree its awkward, I went for putting it close to the actual codegen in the hope that any changes will stay synced up. |
It should be possible to avoid using MUL if it isn't legal. Not sure how much work that would be to fix.
It's generally not a good idea to push vector legalization work to LegalizeDAG; there's a separate legalization stage for vectors precisely because LegalizeDAG can't unroll arbitrary vectors. (This is the issue you mentioned with ARM support for v2i64 multiply.) It would be better to factor out the expansion routine into a separate function, and call it from both VectorLegalizer and LegalizeDAG.