[llvm] [LV] Convert gather loads with constant stride into strided loads (PR #147297)

Mel Chen via llvm-commits llvm-commits at lists.llvm.org
Tue May 5 07:37:23 PDT 2026


================
@@ -7904,16 +7908,21 @@ VPlanPtr LoopVectorizationPlanner::tryToBuildVPlanWithVPRecipes(
                    Range);
   }
 
-  for (ElementCount VF : Range)
-    Plan->addVF(VF);
-  Plan->setName("Initial VPlan");
-
   // Interleave memory: for each Interleave Group we marked earlier as relevant
   // for this VPlan, replace the Recipes widening its memory instructions with a
   // single VPInterleaveRecipe at its insertion point.
   RUN_VPLAN_PASS(VPlanTransforms::createInterleaveGroups, *Plan,
                  InterleaveGroups, RecipeBuilder, CM.isEpilogueAllowed());
 
+  // Convert memory recipes to strided access recipes if the strided access is
+  // legal and profitable.
+  RUN_VPLAN_PASS(VPlanTransforms::convertToStridedAccesses, *Plan, PSE,
+                 *OrigLoop, CostCtx, Range);
----------------
Mel-Chen wrote:

@lukel97 ’s concern is right. We need to account for the permutations of VFs and access types. 

@fhahn Is the primary worry here the compile-time overhead?
If so, my thinking is to:
1. Collect non-contiguous VPWidenLoadRecipe and VPWidenGEPRecipe.
2. Check if the SCEV for VPWidenGEPRecipe is an AddRecurrence.
3. Confirm profitability.
4. Finalize the transformation.

The only uncertainty is whether this might interfere with upcoming items on the TODO list.
```
      // TODO: Transform reverse access into strided access with -1 stride.
      // TODO: Transform gather/scatter with uniform address into strided access
      // with 0 stride.
      // TODO: Transform interleave access into multiple strided accesses.
```
What are your thoughts?

https://github.com/llvm/llvm-project/pull/147297


More information about the llvm-commits mailing list