[llvm] [VPlan] Sink recipes from the vector loop region in licm. (PR #168031)

[Mel Chen via llvm-commits]

================
@@ -2545,6 +2545,58 @@ static void licm(VPlan &Plan) {
       R.moveBefore(*Preheader, Preheader->end());
     }
   }
+
+  VPDominatorTree VPDT(Plan);
+  // Sink recipes with no users inside the vector loop region into a dedicated
+  // exit block.
+  // TODO: Sinking to non-dedicated exits is not supported yet, as it would
+  // require splitting the edge to create a dedicated exit block. Without this,
+  // the sunk instruction would incorrectly execute on paths entering the exit
+  // block from other predecessors.
+  // TODO: Extend to sink recipes from inner loops.
+  for (VPBasicBlock *VPBB : VPBlockUtils::blocksOnly<VPBasicBlock>(
+           vp_post_order_shallow(LoopRegion->getEntry()))) {
+    for (VPRecipeBase &R : make_early_inc_range(reverse(*VPBB))) {
+      if (cannotHoistOrSinkRecipe(R))
+        continue;
+
+      // TODO: Use R.definedValues() instead of casting to VPSingleDefRecipe to
+      // support recipes with multiple defined values (e.g., interleaved loads),
+      auto *Def = cast<VPSingleDefRecipe>(&R);
+      if (Def->getNumUsers() == 0)
----------------
Mel-Chen wrote:

This is actually meant to avoid sinking llvm.assume. Otherwise, from my perspective, even if a recipe has no users, as long as it’s sinkable, we could reduce its execution frequency by sinking it. However, with the current design, having no users means we can’t find a SinkBB. 

Another possible direction for changes might be what was mentioned in https://github.com/llvm/llvm-project/pull/168031#discussion_r2713090357. Perhaps we need to adjust cannotHoistOrSinkRecipe.


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