[all-commits] [llvm/llvm-project] efd493: [VPlan] Handle IV vector splat using VPWidenCanoni...
Florian Hahn via All-commits
all-commits at lists.llvm.org
Sat Jan 29 08:26:04 PST 2022
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: efd4938723efeb26d9cf00ddf217149756c120c3
https://github.com/llvm/llvm-project/commit/efd4938723efeb26d9cf00ddf217149756c120c3
Author: Florian Hahn <flo at fhahn.com>
Date: 2022-01-29 (Sat, 29 Jan 2022)
Changed paths:
M llvm/lib/Transforms/Vectorize/LoopVectorize.cpp
M llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
M llvm/test/Transforms/LoopVectorize/AArch64/sve-tail-folding-forced.ll
M llvm/test/Transforms/LoopVectorize/AArch64/sve-tail-folding.ll
M llvm/test/Transforms/LoopVectorize/AArch64/tail-fold-uniform-memops.ll
M llvm/test/Transforms/LoopVectorize/ARM/mve-gather-scatter-tailpred.ll
M llvm/test/Transforms/LoopVectorize/ARM/mve-reduction-types.ll
M llvm/test/Transforms/LoopVectorize/X86/constant-fold.ll
M llvm/test/Transforms/LoopVectorize/X86/optsize.ll
M llvm/test/Transforms/LoopVectorize/X86/pr34438.ll
M llvm/test/Transforms/LoopVectorize/X86/small-size.ll
M llvm/test/Transforms/LoopVectorize/X86/tail_loop_folding.ll
M llvm/test/Transforms/LoopVectorize/X86/vect.omp.force.small-tc.ll
M llvm/test/Transforms/LoopVectorize/dont-fold-tail-for-const-TC.ll
M llvm/test/Transforms/LoopVectorize/dont-fold-tail-for-divisible-TC.ll
M llvm/test/Transforms/LoopVectorize/first-order-recurrence-sink-replicate-region.ll
M llvm/test/Transforms/LoopVectorize/first-order-recurrence.ll
M llvm/test/Transforms/LoopVectorize/pr44488-predication.ll
M llvm/test/Transforms/LoopVectorize/pr45679-fold-tail-by-masking.ll
M llvm/test/Transforms/LoopVectorize/pr46525-expander-insertpoint.ll
M llvm/test/Transforms/LoopVectorize/pr51614-fold-tail-by-masking.ll
M llvm/test/Transforms/LoopVectorize/select-reduction.ll
M llvm/test/Transforms/LoopVectorize/tail-folding-vectorization-factor-1.ll
Log Message:
-----------
[VPlan] Handle IV vector splat using VPWidenCanonicalIV.
This patch tries to use an existing VPWidenCanonicalIVRecipe
instead of creating another step-vector for canonical
induction recipes in widenIntOrFpInduction.
This has the following benefits:
1. First step to avoid setting both vector and scalar values for the
same induction def.
2. Reducing complexity of widenIntOrFpInduction through making things
more explicit in VPlan
3. Only need to splat the vector IV for block in masks.
Reviewed By: Ayal
Differential Revision: https://reviews.llvm.org/D116123
More information about the All-commits
mailing list