[llvm] [LV] Add -predicated-epilogue option for tail-folded epilogue (PR #190697)

[Hassnaa Hamdi via llvm-commits]

================
@@ -8298,6 +8315,47 @@ getEpilogueLowering(Function *F, Loop *L, LoopVectorizeHints &Hints,
   return CM_EpilogueAllowed;
 }
 
+/// Check if we can apply tail folding to the vectorized epilogue loop,
+/// enabling an unpredicated main vector loop with a tail-folded epilogue
+/// vector loop.
+static bool isEpilogueTailFoldingAllowed(const LoopVectorizationCostModel &CM,
----------------
hassnaaHamdi wrote:

Thanks everyone for the discussion. Here are my thoughts—happy to be corrected if I’m missing something.

@fhahn 

>  When it comes the vectorizing the epilogue, we already check for unsupported patterns directly in the VPlan

I think that could be ok for vectorizing the epilogue, but for folding the epilogue tail, we need to calculate and hold costs, so I think it's better to decide early if tail-folding is doable or not. what do you think ?

@david-arm 

> I don't think that's quite true because computeMaxVF also handles the ScalarEpilogueStatus.

Yes, I see. But I don't think I should add extra logic to that function because I think the function does a lot of work that could be refactored out of it. I think your suggestion of adding the logic to `LoopVectorizationPlanner::plan` makes sense to me.

> I guess at the moment that's difficult to do because we're not actually attempting to create a LoopVectorizationCostModel for the tail-folded plans and so we're only calling computeMaxVF, etc for the non-tail-folded vplan.

Originally I was planning to create the CM instance when that function determines TF is allowed, that's why I included the function in this PR.
Do you think the function maybe better called in `LoopVectorizationPlanner::plan` and I move it to the next PR when I also have the CM instance ?

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