[PATCH] D88380: [VPlan] Extend VPValue to also model sub- & 'virtual' values.

[Ayal Zaks via Phabricator via llvm-commits]

Ayal added a comment.

Extending the recipe abstraction to support def/use relations is an important next step forward for VPlan, thanks for pushing this momentum forward!

Supporting multiple VPValues defined by a single recipe is relevant for VPInterleaveRecipe and to promote idioms such as sincos, add.with.overflow, addsub and potentially more. These are important to recognize and model during vectorization due to their associated atomic costs(*), and to facilitate more advanced "Loop Mixed" vectorization opportunities, where interleave groups form leaves and roots of "Loop aware" SLP trees (CGO'16).
While this multi-valued concept admittedly diverges from LLVM-IR's Instruction-is-a-User-is-a-single-Value, it is consistent with functions returning multiple values in MLIR. Furthermore, VPlan aims to model a region of code with live-ins and live-outs - typically a single loop-nest within a function. A VPValue that is generated by a recipe inside the region and used outside the region, could be represented by feeding a VPUser similar to in-region users; such a live-out VPUser however is out-of-scope, does not correspond to any recipe, and is therefore not a VPValue. Analogously, a VPUser of a recipe inside the region may have an operand from outside the region, which could be represented by a VPValue similar to in-region values; such a live-in VPValue however is out-of-scope, does not correspond to any recipe, and is therefore not a VPUser. The concept of VPDef to hold the zero, one or more VPValues defined by a recipe is analogous to VPUser which holds the operands of a recipe, as proposed by D90558 <https://reviews.llvm.org/D90558>. If/as all live-ins are single values, i.e., all multi-value VPDefs correspond to recipes, recipe and VPDef could be merged into one.

(*) Explicit extract VPInstructions could also be used following a wide VPInstruction load, once introduced into VPlan; but doing so effectively breaks the interleaved-load idiom along with its associated atomic cost.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88380/new/

https://reviews.llvm.org/D88380