[llvm] [VPlan] Use VPInstruction for uniform binops. (PR #141429)

[via llvm-commits]

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

> I think in some cases it can also be seen as property of the producer (e.g. if we proved uniformity for the VF for the specific operation + operands). In those cases, whether a single scalar is produced doesn't depend on either users or operands (e.g. adding a new wide user doesn't change what is produced by the recipe).

Indeed in some cases the producer knows it generates a single scalar, as in reducing a vector to a scalar and extracting a scalar from a vector.
If "we proved uniformity for the VF for the specific operation + operands" and then the operands change - that proof may need to be revisited?

> I think contrary to scalar types, whether the result is a single scalar is currently queried in many more places during various transforms and would be needed when executing each VPInstruction.

Execution and cost arguably need complete type information - both number of elements and type of each element. In addition to the relative frequency of other usages, is the issue of cache-invalidation or updating the type information when recipes are added/removed/replaced/updated.

> The proposed patch would allow us to start the transition by using a similar field to current VPReplicateRecipe and hence simplify VPReplicateRecipe to only handle the replicating case.

This is indeed a good incremental step forward, although replicate recipe still handles remaining uniform cases?

> Similarly we could also use VPInstruction for various VPWiden*Recipes.

> It might be worth consolidating and simplifying the existing recipe classes first, before adjusting how we reason/represent single-scalar/uniformity?

Would be good to make incremental progress alongside clarifying roadmap goal. If current representation is expected to be revisited, worth a note. I.e., reason about the inconsistency between element type information recorded where needed and propagated via type analysis, versus recording IsSingleScalar in each VPInstruction - all other VPSingleDefRecipe's are implicitly non single scalar? All other VPValues are implicitly single scalar - live-ins?

Should `vputils::isSingleScalar(VPInstruction* VPI)` be updated to return `VPI::isSingleScalar()`, w/o considering its operands if it's not?

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