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

+1 for gradually splitting this off.
Suggest this patch temporarily updates simplifyRecipe() to return a single VPRecipeBase* (or none), to be replaced by a small vector of recipes in the subsequent patch along with evident use for it (i.e., simplifying (X && Y) || (X && Z) into (X && (Y || Z)). BTW, this pattern could introduce a single new recipe - by modifying the RAUW'd OR to use Y and Z instead of (X && Y) and (X && Z) - but recipes modified during simplification should also be (re)visited, along with new ones.)

This patch is missing tests, demonstrating the simplification of new recipes introduced when simplifying others, i.e., its non-NFC-ness.

The subsequent patch, extending the code snippet above and following Florian's comment below, could perhaps use a worklist as follows, which could also be outlined into recursivelySimplifyRecipes(NewR):
```
    for (VPRecipeBase &R : make_early_inc_range(*VPBB)) {
      SmallVector<VPRecipeBase *> NewRecipes = simplifyRecipe(R, TypeInfo);
      while (!NewRecipes.empty()) {
        VPRecipeBase *NewR = NewRecipes.pop_back_val();
        append_range(NewRecipes, simplifyRecipe(*NewR, TypeInfo));
      }
    }
```

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