[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