[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