[PATCH] D99509: [RISCV] Add legality check for vectoring reduction
Craig Topper via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Apr 15 09:09:22 PDT 2021
craig.topper added inline comments.
================
Comment at: llvm/lib/Target/RISCV/RISCVTargetTransformInfo.h:130
}
+ bool isLegalToVectorizeReduction(RecurrenceDescriptor RdxDesc,
+ ElementCount VF) const {
----------------
There should be a blank line above this.
================
Comment at: llvm/lib/Target/RISCV/RISCVTargetTransformInfo.h:135
+
+ if (!VF.isScalable())
+ return true;
----------------
frasercrmck wrote:
> I'm wondering if returning `true` for fixed-length vectors, even if correct (i.e. not crashing), is likely to produce worse code. Will it trick the cost modeling into producing code which we'll then expand during legalization, and increase register pressure and the likelihood of spilling?
For most reductions the expansion should be log2(elements) SingleSrcPermute shuffles and binops to reduce elements by half each step. So it shouldn't increase the register pressure much since you just need 2 registers. This should match the default cost model for getArithmeticReductionCost/getMinMaxReductionCost.
That isn't what happens for ordered floating point reduction though, but it also doesn't look like this function is told that it is an ordered reduction. It doesn't look like getArithmeticReductionCost get's told either. Maybe we only vectorize to unordered?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D99509/new/
https://reviews.llvm.org/D99509
More information about the llvm-commits
mailing list