[llvm] [VPlan] Add narrowToSingleScalarRecipe transform. (PR #139150)

[Florian Hahn via llvm-commits]

================
@@ -1086,6 +1086,40 @@ void VPlanTransforms::simplifyRecipes(VPlan &Plan, Type &CanonicalIVTy) {
   }
 }
 
+static void convertToUniformRecipes(VPlan &Plan) {
+  if (Plan.hasScalarVFOnly())
+    return;
+
+  for (VPBasicBlock *VPBB : VPBlockUtils::blocksOnly<VPBasicBlock>(
+           vp_depth_first_shallow(Plan.getVectorLoopRegion()->getEntry()))) {
+    for (VPRecipeBase &R : make_early_inc_range(reverse(*VPBB))) {
+      // Try to narrow wide and replicating recipes to uniform recipes, based on
+      // VPlan analysis.
+      auto *RepR = dyn_cast<VPReplicateRecipe>(&R);
+      if (!RepR && !isa<VPWidenRecipe>(&R))
+        continue;
+      if (RepR && RepR->isUniform())
+        continue;
+
+      auto *RepOrWidenR = cast<VPSingleDefRecipe>(&R);
+      // Skip recipes that aren't uniform and don't have only their scalar
+      // results used. In the latter case, we would introduce extra broadcasts.
+      if (!vputils::isUniformAfterVectorization(RepOrWidenR) ||
+          any_of(RepOrWidenR->users(), [RepOrWidenR](VPUser *U) {
+            return !U->usesScalars(RepOrWidenR);
+          }))
+        continue;
+
+      auto *Clone =
+          new VPReplicateRecipe(RepOrWidenR->getUnderlyingInstr(),
----------------
fhahn wrote:

Currently we don't allow modifying most properties of existing recipes, other than operands and (IR) flags. 

Such a change should probably done separately and we could relax it for some recipes, but creating new recipes here and having dead recipes removed separately later on means we don't really have to worry about invalidating any potential analyses in the future and it I think it mirrors LLVM IR, where creating new instructions is often perferred to modifying existing instructions as it can be less error-prone IIRC.

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