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

[Florian Hahn via llvm-commits]

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

Would you be able to share an IR example for the ZExt issue? It would be interesting to understand if it is similar to the AArch64 issue and in particular with Ext/other opcode combinations are involved.


(I recommitted https://github.com/llvm/llvm-project/commit/90fd99c0795711e1cf762a02b29b0a702f86a264 to get a additional signal into cases where it diverges so I can fix those in parallel to wrapping up the discussion re how to exactly structure the code)

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