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

[Kolya Panchenko via llvm-commits]

nikolaypanchenko wrote:

> With regards to TTI, recipes are defined in terms of IR instructions they generate, so defining the cost of the recipe next to the place where code is generated seems naturally (and I think this also matches the original intended design). We need some state, but that should be only limited to TTI and some analysis like type inference eventually

Isn't it more about code placement ? `CM::getCost(VPInstruction *)` can be placed near to the `execute` function to satisfy that requirement. Similarly, it's possible to just place `VPInstruction::getCost` in a separate file and miss it at code review.
 
> I also mention this in the response below, but I think the first step doesn't mean that everything needs to fit the initial structure in the long run. Once there's a concrete use case that benefits from a different structure we can adjust, while making sure that there's a clear improvement to the current state that's testable.

I still not sure I understand what's a big no-no of a dedicated class to evaluate the cost ? What's a big yes-yes for your proposed approach ?

>  One of the design goals is to model concepts explicitly in VPlan, to avoid having the look across recipes, regions or blocks to compute an accurate cost for any given recipe (e.g. modeling interleave groups explicitly). At the moment, the only concrete example I know of where that is not possible at the moment is arithmetic vector instructions that also can do a sign/zero-extend of some of the operands.

There're multiple cases where "look across recipes" are needed. The most important one, which already exists in some form, is estimation of register pressure. 

> The initial VPlan-based cost model should IMO be solely focused on evaluating the cost per recipe, as this directly maps to the generated IR for which we can query cost.
> There will be other analysis that are not interested in the cost of a single recipe, but other metrics, e.g. resource usage or register pressure when deciding on the interleave count. But those seem to be completely separate from assigning a cost per instruction and could be done completely separately.
> > Switching to a VPlan-based cost-model is likely to cause some disruption if we aren’t careful, so I think to start with we should focus on moving forward with targeted steps, with everything we bring up being used and tested by default. If in the future there are concrete cases where we could benefit from a different structure in terms of where cost is computed and how, we should re-evaluate once we are at this point.

I'd say it's fine, but since your plan is to introduce `VPCostContext`, which is another dedicated object to construct and carry, that seems to be already a plan to not only compute cost per recipe. 

> Just to close the loop here as well, https://github.com/llvm/llvm-project/pull/92555 is the new version based on https://github.com/llvm/llvm-project/pull/67934 with the interfaces refactored/rearranged a bit.

I _do_ think something like that needs to have a broader discussion, not only between couple of people. Tuesday meeting seems to be the right one.

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