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

Yaxun Liu via llvm-commits llvm-commits at lists.llvm.org
Mon May 4 07:22:56 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;
+    }
----------------
yxsamliu wrote:

We do reuse it now. The bypass at the bottom of vectorizeStoreChains is gone. Build-vector stores flow through the normal vectorizeStoreChains -> tryToVectorizeSequence -> vectorizeStores path. The only adjustments are in StoreSorter and AreCompatibleStores, which now use a small getStoreChainType helper so a build-vector store of <N x T> is treated as compatible with scalar stores of T, and a tiny relaxation in AreCompatibleStores so a build-vector store does not have to also match the value-operand instruction shape. The final mixed-slice sink also has a conservative guard that rejects owner stores if there is an intervening memory-reading or memory-writing instruction not already part of the old store sink.

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


More information about the llvm-commits mailing list