[llvm] [VPlan] Delay adding canonical IV increment. (PR #82270)

[via llvm-commits]

ayalz wrote:

> This patch delays adding canonical IV increments, computing the next active lane mask and the branch recipes to exit the vector loop.
> 
> During initial construction of a VPlan, only add the canonical IV phi and active-lane-mask phis if needed. Similarly, do not add the branches to exit the loop initially. Computing the next IV value, the next active-lane-mask or the exit branches are details that are only needed to simplify codegen (execute of the individual recipes).
> 
> This makes the inital VPlans more abstract (and simpler), in that we initially leave out some details. Initial VPlans still have the canonical induction recipe, which provides the value of the canonical induction at every iteration, but we leave out the detail of how it is computed, which is not needed until code generation.
> 
> Similar reasoning applies to active lane mask increments and branch recipes. The vector loop region initially abstractly models the loop processing all vector iterations, without specifying how exactly exiting the region is handled. Again these details are only needed for code generation.
> 
> To introduce the missing pieces and complete the abstract VPlan, a new prepareToExecute transform is added and run just before exiting the VPlan.
> 
> This is an attempt to further employ gradual lowering, as outlined in https://llvm.org/devmtg/2023-10/slides/techtalks/Hahn-VPlan-StatusUpdateAndRoadmap.pdf and already applied for replicate region handling.

Having the canonical IV phi (i.e., the iteration number of the vector loop), and the active lane mask phi (i.e., the mask of the vector loop header), as abstract VPValues during first (possibly most) VPlan transformations, leaving the introduction of recipes along their associated cyclic chains to a later stage, sounds great! However, placing them as regular header phi recipes inside the header block, as placeholders - w/o feeding or being fed along their associated cyclic def/use chains, seems inconsistent: header phi recipes are expected to have two operands, one fed across the back-edge; w/o it, what's to keep the recipe from being hoisted to the preheader. As placeholders these recipes continue to maintain their current concrete semantics themselves, rather than being abstract.

An alternative (discussed w/ @aniragil ): have VPRegionBlock hold the canonical IV and active lane mask as VPValues, rather than having the header VPBasicBlock hold them as header phi recipes. Such VPValues are neither recipes nor live-ins - whose scope is the entire VPlan, which holds them. These VPValues can be used by any recipe inside the loop region (including header phi recipes?) or inside the middle block. These VPValues are destined to be materialized into header-phi + increment + loop branch recipes when the VPRegionBlock is replaced by CFG, prior to code-gen, or earlier if desired. WDYT?

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