[llvm] [VPlan] Introduce multi-branch recipe, use for multi-exit loops (WIP). (PR #109193)

[Florian Hahn via llvm-commits]

fhahn wrote:

> For what it's worth I already have a patch upstream that performs auto-vectorisation of early exit loops - #88385. It's out of date now because I've been trying to incrementally land bits of that patch and was waiting for a good chance to rebase. In that original patch I was also trying to hide some of the structure from VPlan, but I did it in a different way by keeping the early exiting VPBlock in VPlan and hiding the successor off to the side. This avoided requiring multiple successors from the VPRegionBlock. After discussion with and help from @huntergr-arm, I then came up with #108563 as an attempt to model the early exits more formerly in VPlan by mapping an early exiting VPBlock to a VPRegionBlock successor.
> 


The goal of the patch is solely to sketch an option  to model early exits in VPlan that retains the single-entry-single-exit property (hence allowing to also support other code after the early exits via predication and/or multiple early exits) and models all required info directly in the VPlans explicitly, not  to implement support vectorizing a new class of loops. There is some scaffolding to generate VPlans with the new recipes, but that is only limited to a subset of the early exit loops we already support and I'd be more than happy to remove as much of that as possible.

> One of the problems I see with this patch is how to model VPLiveOuts correctly in a way that doesn't require a lot more special handling. With PR #88385, although not perfect and too huge in it's original form, I was hoping to move towards a model where we could reuse the existing VPLiveOut class and map incoming VPValues to incoming VPBlocks, which requires having individual exiting VPBlocks in the VPRegionBlock. The benefit of this approach was being able to reuse the existing plumbing to update PHI values correctly according to the block they exited from. I was even hoping to simplify `fixPhi` at some point so that we don't have to try so hard to figure out what the predecessor VPBlock is for normal exits.
> 

Just replied to https://github.com/llvm/llvm-project/pull/109975#issuecomment-2386994488 with a suggestion of how the exit values could be modeled using the more flexible infrastructure added recently. I also updated the PR to support updating exit phis, only limited to the simplest cases where the incoming values is a live-in (just to make sure everything fits together). The VPlans in https://github.com/llvm/llvm-project/pull/109193/files#diff-c33c5be02bdbedc5499230934c8fc873429b771425f21c3f594acb6fae6339d7 should illustrate both the cases where there  are 2 separate exit blocks and a shared one.


> I'm not sure what effect this patch has on plans for the cost model, since if I understand correctly we're moving towards a cost model based on the VPlan structure and its recipes?

The patch shouldn't really have implications for the VPlan-based cost model either way, as VPInstruction costs are not computed via VPlan yet. We should be able to move to computing at least the cost of the backedge using the VPlan-based cost model soon though. 


> Hi @fhahn, can you attend the next community vectoriser call on 15th October? I thought maybe this is a good place to discuss the best approach for moving forward with PR https://github.com/llvm/llvm-project/pull/88385, since we want to add support for vectorising early exit loops in the next LLVM release. If so, @hiraditya would it be possible to add this is an agenda item please? Thanks!

Sounds good, I should be able to attend.


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