[llvm] [SLP] Support ordered fadd reduction via reduction intrinsics (PR #189451)
Ryan Buchner via llvm-commits
llvm-commits at lists.llvm.org
Sat May 9 13:40:30 PDT 2026
================
@@ -29046,6 +29138,239 @@ class HorizontalReduction {
return VectorizedTree;
}
+ /// Attempt to vectorize an ordered (linearized) reduction chain.
+ /// Reduced values from matchOrderedReduction() are in accumulation order.
+ /// Vectorized subsets are immediately reduced via ordered reduction
+ /// intrinsics; non-vectorized values are folded linearly.
+ Value *tryToReduceOrdered(BoUpSLP &V, const DataLayout &DL,
+ TargetTransformInfo *TTI,
+ const TargetLibraryInfo &TLI, AssumptionCache *AC,
+ DominatorTree &DT) {
+ constexpr unsigned RegMaxNumber = 4;
+ constexpr unsigned RedValsMaxNumber = 128;
+
+ assert(RK == ReductionOrdering::Ordered && "Expected ordered reduction");
+ assert(ReducedVals.size() == 1 &&
+ "Expected single group from matchOrderedReduction");
+
+ IRBuilder<TargetFolder> Builder(ReductionRoot->getContext(),
+ TargetFolder(DL));
+ Instruction *RdxRootInst = cast<Instruction>(ReductionRoot);
+ Builder.SetInsertPoint(RdxRootInst);
+
+ SmallVector<Value *> Candidates(ReducedVals.back());
+
+ // Intersect the fast-math-flags from all reduction operations.
+ FastMathFlags RdxFMF;
+ RdxFMF.set();
+ for (Value *RdxVal : Candidates)
+ for (Instruction *Op : ReducedValsToOps.at(RdxVal))
+ if (auto *FPMO = dyn_cast<FPMathOperator>(Op))
+ RdxFMF &= FPMO->getFastMathFlags();
----------------
bababuck wrote:
In a test case where I set the `reassoc` flag, I noticed that the output is `reassoc llvm.vector.reduce.fadd`, but I was wondering if it would be better to output `llvm.vector.partial.reduce.fadd` in such cases
e.g
```
%add28 = fadd reassoc float %add6, %add11
%add29 = fadd reassoc float %add28, %add16
%add30 = fadd reassoc float %add29, %add21
```
https://github.com/llvm/llvm-project/pull/189451
More information about the llvm-commits
mailing list