[llvm] [LV] Reduce register pressure of RISC-V outer loop reduction. (PR #208621)

[Mel Chen via llvm-commits]

Mel-Chen wrote:

> > Does this mean vp.merge doesn't need to calculate cost in this situation? If so, we might as well combine the in-loop operation and vp.merge into a new VPExpressionRecipe. This way, we could fix both the cost and register pressure issues at the same time.
> 
> Ah, I probably didn't describ this issue quite well. This patch is trying to fix the register pressure for outer loop reductions not for expression recipes. VPExpressionRecipe is kind of in-loop reduction, which will generate `vp.merge` before the reduction (for partial-reduction) or generate `vp.reduce` for (non-partial in-loop reductions).
>

What I mean is, the chain tail of VPExpressionRecipe shouldn't be limited to VPReductionRecipe. We should be able to extend it so that vp.merge can also serve as the chain tail.
By folding the in-loop operation and vp.merge into a single VPExpressionRecipe, we can ignore the cost of vp.merge and address the register pressure issue.

> Do we need a new TTI hook if we add a VPExpressionRecipe type? Or would we just always assume that a vp.merge will be free and folded in? Although RISC-V is the only target that will emit vp.merge, it being folded away is a target specific assumption.

Yes, I think we should. IIUC, this is folded in RISCVVectorPeephole.cpp? If that's the case, it would be best to have a function that explicitly indicates the target is capable of folding specific pattern of vp.merge.



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