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

[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);
----------------
ayalz wrote:

> Thanks for splitting this off. A next step could be for the work-list to also re-queue users of a simplified value for further simplification. With the current interface, we would have to create and return a number of temporary vectors for each simplification. Just wondering what your thoughts are about adding the the worklist in `simplifyRecipe`

Regarding re-queueing user: the only users affected are those of the root recipe, via RAUW. 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, and (b) each original recipe is simplified completely, possibly including simplifying new recipes recursively, before moving to the next. Right?

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