[llvm] [VPlan] Introduce scalar loop header in plan, remove VPLiveOut. (PR #109975)

[David Sherwood via llvm-commits]

david-arm wrote:

> Sure. Curious if you hit any limitations with VPIRInstruction that prevent it from replacing VPLiveOut?

Yeah, so in my comment earlier last week I highlighted the problem of ordering constraints. If the same exit block is used by both the latch and the early exit, then the phi in the exit block should have an incoming value for both of the exiting blocks. If I add operands to the VPIRInstruction wrapper - one for each exiting block - then in the VPIRInstruction::execute code using a patch you sketched out in https://github.com/llvm/llvm-project/commit/3cfe25bf43feaf94d319c7f804e5c73c45f96057 we introduce a requirement that the order of the extra operands *must* match the order of the predecessors. `replaceVPBBWithIRVPBB` breaks this by reordering them, hence I put up a patch yesterday to preempt this - https://github.com/llvm/llvm-project/pull/111514. Perhaps it's fine to introduce this ordering constraint, but I wonder if this makes the code fragile and prone to breaking every time we do some CFG optimisation? Secondly, the phi may or may not reference an induction variable in the loop, which is handled separately to VPIRInstruction::execute. However, you still need to add some sort of dummy operand because the number of operands *must* match the number of predecessors. I have hacked this downstream by adding a static 'null' VPValue marker that we can skip over the operand in VPIRInstruction::execute.

Another approach would be to introduce a new class derived from VPIRInstruction, i.e. VPIRPhiInstruction that maintains a mapping between the extra operand and the incoming block. I haven't tried this second approach - this is potentially more flexible, but it is moving a bit further away from having a simple IR wrapper and is moving back towards something like VPLiveOut.

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