[llvm] [RFC][LV] VPlan-based cost model (PR #67647)

[Shih-Po Hung via llvm-commits]

arcbbb wrote:

> Thanks for sharing this as PR, it is great to see people interested in pushing in that direction!
> 
> Some high-level thoughts:
> 
> * Using the VPlan cost model to pick the  vectorization factor seems like a great idea!
> * Bring-up should happen on-by-default and gradually; if there are any issues, we want to know about it ASAP, otherwise it might be very very difficult to flip the switch.
> * If possible, the VPlan based cost model implementation should be completely separated from the legacy cost model, to make sure the VPlan cost model can stand on its own (and to avoid temptation)
> * The cost model should be as independent of the underlying IR as possible;  some recipes may not have an underlying instruction to use and even if they do, the type info may not be correct (e.g. when applying truncation as VPlan-to-VPlan transform, https://reviews.llvm.org/D149903)
> * I think it makes sense to have the code to compute costs for recipes in the recipe itself; the recipe already knows how to generate the code, so it seems like the right place to also compute the cost of the generated code; that makes it even more important to be completely independent of the legacy cost model.
> 
> I tried to sketch an alternative structure in #67934 which addresses some of those points. It consists of a type-inference for VPValues as build block.
> 
> It only implements costs for `VPWidenRecipe` and `VPWidenIntOrFpInductionRecipe` (only limited to compute the same cost as the legacy cost model). Those are used by a `getBestVPlan` helper in `LoopVectorizationPlanner`, which asks recipes for their cost and if not implemented yet falls back to using the legacy cost model as a stop-gap until all recipes implement computing their cost. For testing, the patch uses `getBestPlan` to get the VPlan to execute, combined with an assertion that the most profitable VF matches the VF computed by the legacy cost model. At the moment, this passes for SPEC2017,MultiSource,SingleSource on AArch64.
> 
> Before filling out all the cost implementations, I think we should converge on the overall structure. This PR already implements costs for several recipes, which is great as hopefully we will be able to fill in the gaps soon!

I agree that using the legacy cost model during the transition period is a prudent approach to ensure stability,
and I appreciate the alternative approach on type inference - seems like a better way to go!

About computing cost in the recipe itself, I see your point.
In addition to compute the throughput cost, we might consider other costs like register spills and loop exit overhead, so I prefer a separate class for these cost computation to avoid the need to increase the number of the VPRecipeBase interfaces and treat it as a kind of IR.

Do you want to get your PR reviewed and merged first?

Here's hoping we can get those implementations filled in soon!

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