[llvm] [VPlan] Scalarize to first-lane-only directly on VPlan (PR #184267)

Andrei Elovikov via llvm-commits llvm-commits at lists.llvm.org
Mon May 4 09:27:54 PDT 2026


================
@@ -6405,3 +6405,52 @@ void VPlanTransforms::makeMemOpWideningDecisions(
     ReplaceWith(Recipe);
   }
 }
+
+void VPlanTransforms::makeScalarizationDecisions(VPlan &Plan, VFRange &Range) {
+  if (LoopVectorizationPlanner::getDecisionAndClampRange(
+          [&](ElementCount VF) { return VF.isScalar(); }, Range))
+    return;
+
+  PostOrderTraversal<VPBlockDeepTraversalWrapper<VPBlockBase *>> POT(
+      Plan.getEntry());
+  for (VPBasicBlock *VPBB : VPBlockUtils::blocksOnly<VPBasicBlock>(POT)) {
+    for (VPRecipeBase &R : make_early_inc_range(reverse(*VPBB))) {
+      auto *VPI = dyn_cast<VPInstruction>(&R);
+      if (!VPI)
+        continue;
+
+      // For now we (effectively) only scalarize to first-lane-only address
+      // computation chain for the memory operations.
+
+      auto *I = cast_or_null<Instruction>(VPI->getUnderlyingValue());
+      // Wouldn't be able to create a `VPReplicateRecipe` anyway.
+      if (!I)
+        continue;
+
+      // If "executing" other lanes produces side-effects we can't avoid them.
+      if (VPI->mayHaveSideEffects())
+        continue;
+
+      // We want to drop the mask operand, verify we can safely do that.
+      if (VPI->isMasked() && !VPI->isSafeToSpeculativelyExecute())
----------------
eas wrote:

I don't think we should do that. Operation might become a replicate recipe later, and be costly (e.g., division). Unmasking it shouldn't be predicator's job.

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


More information about the llvm-commits mailing list