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

[Florian Hahn via llvm-commits]

fhahn 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.

Sure, in the end the whole discussion boils down to code placement.

> > 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 ?
> 

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.


> 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.
> 

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?

> > 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.
> 

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.



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