[llvm] [DAGCombiner] Limit EXTRACT(SETCC) combines in scalarizeExtractedBinOp to i1 types (PR #123071)
David Sherwood via llvm-commits
llvm-commits at lists.llvm.org
Thu Jan 16 01:31:24 PST 2025
================
@@ -22809,7 +22809,8 @@ static SDValue scalarizeExtractedBinOp(SDNode *ExtElt, SelectionDAG &DAG,
EVT ResVT = ExtElt->getValueType(0);
if (Opc == ISD::SETCC &&
- (ResVT != Vec.getValueType().getVectorElementType() || LegalTypes))
+ (ResVT != Vec.getValueType().getVectorElementType() || ResVT != MVT::i1 ||
----------------
david-arm wrote:
Hmm, I tried that just now and I'm not sure how to make this work. The problem only occurs when ResVT is not MVT::i1 when I have to worry about possibly sign-extending. If I try using the check:
```
TLI.getBooleanContents(Vec.getValueType()) == TargetLowering::ZeroOrNegativeOneBooleanContent
```
instead of `ResVT != MVT::i1` then none of the optimisations in `AArch64/extract-vector-cmp.ll` take place because even MVT::v4i1 types are set to ZeroOrNegativeOneBooleanContent. What I can do is to make this less conservative by doing:
```
(ResVT != MVT::i1 && TLI.getBooleanContents(Vec.getValueType()) == TargetLowering::ZeroOrNegativeOneBooleanContent)
```
so that we still perform the optimisation for targets where we only care about the first bit. Alternatively, I'm thinking perhaps I can just support the optimisation by manually inserting sign extends, however I was initially just focussed on fixing the bug before the branch point and avoiding increasing code complexity. But maybe it's better to just support it?
https://github.com/llvm/llvm-project/pull/123071
More information about the llvm-commits
mailing list