[llvm] [LV] Optimize VPWidenIntOrFpInductionRecipe for known TC (PR #118828)

[Hari Limaye via llvm-commits]

================
@@ -661,14 +661,16 @@ static void recursivelyDeleteDeadRecipes(VPValue *V) {
   }
 }
 
-void VPlanTransforms::optimizeForTCAndVF(VPlan &Plan, unsigned TC,
-                                         ElementCount BestVF) {
+void VPlanTransforms::optimizeForTCAndVFAndUF(VPlan &Plan, unsigned TC,
+                                              ElementCount BestVF,
+                                              unsigned BestUF) {
   assert(Plan.hasVF(BestVF) && "BestVF is not available in Plan");
+  assert(Plan.hasUF(BestUF) && "BestUF is not available in Plan");
   if (!TC || !BestVF.isFixed())
     return;
 
-  // Calculate the widest type required for known TC and VF.
-  uint64_t Width = BestVF.getKnownMinValue();
+  // Calculate the widest type required for known TC, VF and UF.
+  uint64_t Width = BestVF.getKnownMinValue() * BestUF;
----------------
hazzlim wrote:

Ah good point. I've added a test - but this PR will still not trigger on the case when we are interleaving. This is because when unrolling the induction by UF, we create new recipes for the induction steps for part 1 .. UF, which are users of the original IndVar. As this PR limits to only a single use (Cmp) of the IndVar, this case will not be optimized.
https://github.com/llvm/llvm-project/blob/fbc18b85d6ce5ab6489a2b08f9b38d446fe9d6f6/llvm/lib/Transforms/Vectorize/VPlanUnroll.cpp#L186-L218

I am thinking we could leave extending this to a follow-up PR, if you agree?

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