[llvm] [LV] Support binary and unary operations with EVL-vectorization (PR #93854)
Kolya Panchenko via llvm-commits
llvm-commits at lists.llvm.org
Tue Jun 25 14:28:54 PDT 2024
================
@@ -8457,14 +8457,15 @@ void LoopVectorizationPlanner::buildVPlansWithVPRecipes(ElementCount MinVF,
for (ElementCount VF = MinVF; ElementCount::isKnownLT(VF, MaxVFTimes2);) {
VFRange SubRange = {VF, MaxVFTimes2};
if (auto Plan = tryToBuildVPlanWithVPRecipes(SubRange)) {
+ bool IsScalarVPlan = Plan->hasVF(ElementCount::getFixed(1));
// Now optimize the initial VPlan.
- if (!Plan->hasVF(ElementCount::getFixed(1)))
+ if (!IsScalarVPlan)
VPlanTransforms::truncateToMinimalBitwidths(
*Plan, CM.getMinimalBitwidths(), PSE.getSE()->getContext());
VPlanTransforms::optimize(*Plan, *PSE.getSE());
// TODO: try to put it close to addActiveLaneMask().
// Discard the plan if it is not EVL-compatible
- if (CM.foldTailWithEVL() &&
----------------
nikolaypanchenko wrote:
> Hm, does it make sense to create VPlans with EVL in general? IIUC it doesn't and this could be done independent of the patch.
Not sure I follow.
> widen loads and stores shouldn't be created in a scalar plan, I guess at the moment this just works as there are no recipes that can be in scalar plans and get converted to an EVL version without this patch.
I double checked the code and looks like I got confused with `VPInstruction`. So I agree `VPWidenRecipe` won't be a problem. Will move it to a separate patch
https://github.com/llvm/llvm-project/pull/93854
More information about the llvm-commits
mailing list