[llvm] [SLP] Split blocking build-vector stores in scalar chains (PR #194970)

Alexey Bataev via llvm-commits llvm-commits at lists.llvm.org
Fri May 1 22:03:03 PDT 2026


================
@@ -31313,14 +31081,26 @@ bool SLPVectorizerPass::vectorizeStoreChains(BoUpSLP &R) {
     LLVM_DEBUG(dbgs() << "SLP: Analyzing a store chain of length "
                       << Pair.second.size() << ".\n");
 
-    if (!isValidElementType(Pair.second.front()->getValueOperand()->getType()))
+    if (!isValidElementType(getStoreChainType(Pair.second.front())))
       continue;
 
     // Reverse stores to do bottom-to-top analysis. This is important if the
     // values are stores to the same addresses several times, in this case need
     // to follow the stores order (reversed to meet the memory dependecies).
     SmallVector<StoreInst *> ReversedStores(Pair.second.rbegin(),
                                             Pair.second.rend());
+    // `tryToVectorizeSequence` filters whole StoreInsts before vector-store
+    // lanes exist, so it cannot represent a mixed scalar/build-vector store
+    // range. Keep that bypass narrow and let vectorizeStores build StoreLanes
+    // before the normal RelatedStoreInsts / StoreChainContext modeling.
+    if (any_of(ReversedStores, [](StoreInst *SI) {
+          SmallVector<Value *, 16> Elts;
+          SmallVector<Instruction *, 16> Insts;
+          return collectBuildVector(SI->getValueOperand(), Elts, Insts);
+        })) {
+      Changed |= vectorizeStores(ReversedStores, R, Attempted);
+      continue;
+    }
----------------
alexey-bataev wrote:

Why cannot reuse original vectorizeStores? Just try to adjust the sorters/matchers, this approach cuts off many potential candidates

https://github.com/llvm/llvm-project/pull/194970


More information about the llvm-commits mailing list