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

[Kolya Panchenko via llvm-commits]

nikolaypanchenko wrote:

> I don't think there's a big yes-yes or no-no for either. I think the most important bit is getting started on transitioning the cost computations without regressions; using overloading is probably slightly more compact than having a separate cost model class with some kind of type switch initially, but I don't feel strongly about it. I mostly have been trying to better understand the benefit/desire to have it separate.

Understood. Having a proper separation of concerns, I [mentioned earlier](https://github.com/llvm/llvm-project/pull/67647#issuecomment-2086374074) is a big reason to me (otherwise it's not clear what should be a part of VPlan/Recipe and what should not be: should transforms and verification be a part of VPlan ?) 
 
> Is this the case in the current cost-model for instruction costs? We try to estimate the register pressure when picking the interleave factor, but that's completely separate from computing instruction costs at least at the moment?

That's exact the reason internally we added vplan-based cost model, since current regpressure heuristic is only used to trim down VF/IF candidates, but is not used later during loop estimation. Without it loop with multiple live registers and zexts was assumed profitable. 

> I'm not sure why that would be the case? It only contains global info needed for TTI queries + state that's used temporary during the transition from the legacy CM which unfortunately seems needed during the initial bringup.

If we do consider basic estimation only, entire debate from my side is "tomato-tomato": in both cases object needs to be constructed:
```
VPCostContext Ctx(Analyses);
Plan.cost(...Ctx..., VF)
```
vs
```
VPlanCostModel CM(Analyses);
CM.cost(Plan, VF)
```
but when it's become essential to know context around instruction, I do see that proper separation is essential.

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