[llvm] VPlan: introduce worklist in simplifyRecipes (PR #105699)

[Ramkumar Ramachandra via llvm-commits]

================
@@ -1009,8 +1015,16 @@ static void simplifyRecipes(VPlan &Plan, LLVMContext &Ctx) {
       Plan.getEntry());
   VPTypeAnalysis TypeInfo(Plan.getCanonicalIV()->getScalarType(), Ctx);
   for (VPBasicBlock *VPBB : VPBlockUtils::blocksOnly<VPBasicBlock>(RPOT)) {
-    for (VPRecipeBase &R : make_early_inc_range(*VPBB)) {
-      simplifyRecipe(R, TypeInfo);
+    // Populate a Worklist, as simplifyRecipe might return a new recipe that we
+    // need to re-process.
+    SmallVector<VPRecipeBase *> Worklist;
+    for (auto &R : VPBB->getRecipeList())
+      Worklist.push_back(&R);
+
+    while (!Worklist.empty()) {
+      VPRecipeBase *R = Worklist.pop_back_val();
+      for (VPRecipeBase *Cand : simplifyRecipe(*R, TypeInfo))
+        Worklist.push_back(Cand);
----------------
artagnon wrote:

They should be visited, w/o re-queueing, as long as (a) recipes are simplified in def-use order - as in from first to last in block,

Isn't the current order a reverse-post-order-traversal? When stepping through the code, I see that recipes are simplified from the last instruction in the block to the first instruction in the block.

Will make_early_inc_range automatically pick up RAUW'd definitions? I thought it would skip modified (or replaced) definitions altogether.

and (b) each original recipe is simplified completely, possibly including simplifying new recipes recursively, before moving to the next. Right?

I'm a little worried that we're painting ourselves into a corner by imposing the condition that `simplifyRecipe` only ever returns a single newly-introduced (sub)recipe.

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