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

[Kolya Panchenko via llvm-commits]

nikolaypanchenko 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!

@fhahn 
Even though I understand adding `::computeCost` to `VPlan`/`VPRecipe`/`VPInstruction`/etc is aligned with current design of a `VPlan` which has `::execute` methods there. However, cost model is usually what downstream compilers modify and may not want to upstream due to the policies. With that, a dedicated object for the cost model that takes VPlan and computes the cost of it makes life easier for downstream compilers to modify code without adding to much pain to pulldowns.
That is, if upstream compiler has a base version
```c++
class VPlanCostModel {
  virtual int64_t getCost(VPlanPtr);
  virtual int64_t getCost(VPInstruction *VPInst);
  ...
};
```
downstream compiler, if it wants to have its own implementation may override some of these functions:
```c++
class VPlanCostModelDownstream : public VPlanCostModel {
  int64_t getCost(VPInstruction *VPInst) override;
  ...
};
```
with minor change when VPCM is constructed.
In both cases extra object is necessary, but entire state/context of the cost model is isolated in `VPlanCostModel`.

btw, do you know why `::execute` methods were added to a VPlan instead of having something like `VPlanCodeGen` ?

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