[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