This patch extends VPValue to model 3 different kinds of VPValues:
- Concrete VPValues Concrete VPValues are either live-ins coming from IR or instructions/ recipes in VPlan which produce a single value. They are the most common kind.
- Sub VPValues Sub-VPValues are result values from instructions/recipes in VPlan that produce multiple values. They contain a reference to the producing 'virtual' VPValue.
- Virtual VPValues Virtual VPValues are used to model instructions/recipes that either produce multiple subvalues or no values at all. A virtual VPValue does not refer to a concrete value, which means it cannot be used like concrete or subvalues. For example, they cannot be used as operands. They can be used to traverse the def-use chains upwards. They also provide convenient access to all users of all sub-values of the producer.
Most existing recipes will be concrete VPValues (e.g. VPInstruction,
VPWidenRecipe & so on).Sub-VPValues can be used to model multiple result
values for VPInterleaveRecipe. VPInterleaveRecipe itself is a 'virtual'
VPValue, which allows for convenient traversal of the def-use chains.
The main advantage of handling everything in a VPValue over introducing
a new sub-class for sub-values (D87752) is that it slightly simplifies
things further down the road, by turning VPRecipeBase itself directly
into a VPValue. This simplifies things, by removing the duplicated
Following on this patch, we could make VPRecipeBase inherit from VPValue (D88379)
and VPUser (D88378), which should allow full traversal. Note that for the last 2 patches,
we should probably migrate the remaining recipes to manage operands using VPUser and
turn them into VPValues individually.