[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