[llvm] [VPlan] Track VPValue names in VPlan. (PR #81411)

[via llvm-commits]

ayalz wrote:

> > It seems somewhat more natural to assign a name to a VPValue/single-VPValued-recipe upon construction (as done now for VPInstructions) rather than post-construction when it is inserted into a VPlan. The latter is required in order to ensure all names of a VPlan are unique, by having VPlan store all names of its VPValues in a set. Having a VPValue lose its name when taken out of its Block/VPlan, possibly temporarily, seems also less desirable.
> > One alternative may be to utilize VPRecipeBuilder to create all (named) recipes, along with their preset VPlan/insertion-point.
> > Another alternative may be to assign possibly duplicated "core" names to recipes upon construction, and check uniqueness later upon insertion into VPlan or even upon printing by VPSlotTracker, resolving duplication by adding the enumerating suffix (possibly removing the suffix upon removal from VPlan). If VPSlotTracker assigns suffixes, they would be assigned in program order, but only when dumping the entire VPlan.
> > Another approach may be to associate a recipe with its VPlan upon construction, permanently and directly, rather than via its Block which is subject to insertion and removal.
> > Another independent thought, raised by Gil, is to fill Opcode-dependent meaningful names such as "sum" for Add, "diff" for Sub, "prod" for Mul, etc.
> 
> I think overall it would be preferable to use either VPBuilder or VPRecipeBuilder for recipe construction + insertion. I updated some places to do so to remove the need to set names after the fact in most cases.
> 
> Also updated to remove passing the name to `appendRecipe`. Instead I updated `::insert` to use the underlying value's name, if it has one automatically.
> 
> The current approach in the patch mirrors how names of `Value` are managed, but what makes this work not was nicely with VPlan is that most recipe's constructors don't have a reliable way to retrieve a VPlan before they are inserted (contrary to `Value`, where the context always can be retrieved via it's operands).
> 
> Alternatively we could add a `std::string` to `VPValue` to hold the name, and possibly indicate that the suffix may not be correct by adding `?` as suffix unless a recipe has been inserted in a plan?

On one hand, a name seems like a persistent property of a VPValue, to be initialized upon construction and retained regardless of being placed inside or being taken out of a VPlan, so perhaps an std::string within VPValue. Ensuring names are unique can either be done upon construction (in construction order, w/ or w/o recycling), possibly by introducing a VPlanContext to hold names of all VPlan entities, or upon printing (in program order), as already done by VPSlotTracker.

OTOH,
- a name is for debugging only,
- of VPlan only: w/o delegating to names of IR Values when generating them,
- dictated for Live-ins-with-underlying-IR,
- Live-ins-w/o-underlying-IR (nor access to a VPlan, unless one tries to track users) are temporary cases, which could be dealt with using a designated subclass,
- specific names are currently assigned in only two cases: "index.next" of the CanonicalIVIncrement (VPInstruction with Add opcode), and "next.gep" (VPInstruction with PtrAdd opcode).

So perhaps (1) dictate names for all recipes, derived from their class or opcode, and (2) inferring them uniquely when printed?

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