[llvm] [LV][EVL] Generate negative strided load/store for reversed load/store (PR #123608)

Pengcheng Wang via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 6 01:03:05 PST 2025


wangpc-pp wrote:

> > > But if that's the case, wouldn't it be sufficient to just modify computeCost, keep load + reverse, and convert it into strided accesses in CodeGenPrepare?
> > 
> > 
> > I guess it depends on what we want the canonical form for a reversed load to be, i.e. a vp intrinsic or load + reverse. My preference would be the former since it's easier to pattern match.
> > Although I didn't realise this would be unprofitable on x280, in that case I think its reasonable if we want to check the cost of `getStridedMemoryOpCost` vs `getMemoryOpCost + getShuffleCost` and choose the cheaper lowering option as @arcbbb suggested earlier. That way the cost for the recipe would just be the minimum of the 2.
> 
> Sounds good :)

For current vectorizer framework, I think it is not easy to implement choosing lowering methods based on cost. We compute the cost for different `VF` and `CostKind` but when executing the VPlan, the VF has been choosen. There is a gap between cost modeling and VPlan's execution. We may add a map (VF/CostKind -> lowering method) to Recipe and query the decision for execution VF. I'd like to do such thing in a future follow-up. :-)

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


More information about the llvm-commits mailing list