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

Florian Hahn via llvm-commits llvm-commits at lists.llvm.org
Thu Mar 14 04:59:53 PDT 2024


https://github.com/fhahn commented:

> 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?

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


More information about the llvm-commits mailing list