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

Yes, that creation of two new recipes follows the suggestion in https://github.com/llvm/llvm-project/pull/89386#discussion_r1579120585, thanks! Hence **currently**.

Regarding the order in which recipes are visited when trying to simplify each:

Instead of simplifying (X && Y) || (X && !Y) directly into X, we can first simplify into (X && (Y || Z)) where Z is !Y, introducing two new recipes. Then the new recipe (Y || Z) should be visited and simplified into 'true' followed by visiting the other new recipe (X && 'true') and simplifying it into X. How will the two new recipes be simplified if they are visited in the other order?

In addition to the order above of newly introduced recipes among themselves, once a recipe is simplified and RAUW'd, it may be potential to try to simplify its users - preferably **after** trying to simplify all its new recipes? E.g., ((X && Y) || (X && !Y)) || !X). I.e., should new recipes be appended into the worklist at its **front** rather than at its **back**.

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