[llvm] [VPlan] Use VPInstructionWithType for uniform casts. (PR #140623)

[via llvm-commits]

================
@@ -919,6 +919,9 @@ class VPInstruction : public VPRecipeWithIRFlags,
                       public VPUnrollPartAccessor<1> {
   friend class VPlanSlp;
 
+  /// True if the VPInstruction produces a single scalar value.
+  bool IsSingleScalar;
+
----------------
ayalz wrote:

For the purpose of this patch, which models uniform cast operations via VPInstructionWithType instead of VPReplicateRecipe, suffice to introduce IsSingleScalar in VPInstructionWithType, rather than VPInstruction?

Adding IsSingleScalar to VPInstruction potentially lays the ground for future handling beyond VPInstructionWithType-for-scalar-casts. This raises several questions going forward: (1) what information to record - an IsSingleScalar bit or more? (2) where to record it - everywhere or only where needed? (3) how does this relate to Type information?

Regarding (1): every VPValue may represent (a) a single scalar, (b) multiple scalars (VFxUF, VF after unrolling), or (c) a single vector (of VFxUF elements, VF after unrolling). Note that "VF" may differ from the one common across a vector loop, when considering interleaved groups and/or SLP.

Regarding (2): Single scalar information may be inferred from uniformity/divergence analysis coupled with demanded-elements analysis (only first lane used), analogous to min-bitwidth information inferred from range propagation coupled with demanded bits. The latter encodes its results, i.e., the narrower element Type of VPValues, only where needed: in live-ins and type-changing casts, relying on VPTypeAnalysis to infer the types of other VPValues. Suffice to record single-scalar-ness also only where needed - recipes that create or change this behavior, relying on vputils::isSingleScalar() for other VPValues (possibly caching its results as in VPTypeAnalysis)? Casts OTOH typically modifying only the element type of their operand - retaining its single-scalar-ness, as in PreservesUniformity.

Regarding (3): single-scalar-ness could potentially be recorded alongside the element Type, as in LLVM-IR: can use Array type for (b), scalable vector type for (c), and neither - plain element type for (a). Can alternatively introduce VPType which holds information (1) alongside but separate from the element Type. In both cases it would seem natural for VPInstructionWithType to represent information (1).

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