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

[Florian Hahn 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;
----------------
fhahn wrote:

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

Yep I think that would be good to re-visit at some point.

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

Most recipes w/o attached type can construct IR instruction w/o querying the type explicitly as opcode + operands is sufficient in most cases. For cost, both will be needed.


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

Yep there's still some way to go to complete the full transition. Would probably be good to start with one of the simplest cases first (casts, https://github.com/llvm/llvm-project/pull/140623), then binops, then the rest.

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

There are some recipes that are always scalar (e.g. `VPCanonicalIVPhi`), but after the transition allmost all other cases should be VPInstruction with IsSingleScalar set.


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

I think it at least in the first patch (casts,  https://github.com/llvm/llvm-project/pull/1406230) it is too early, as we don't yet set it for all relevant opcodes . But once we set it for all relevant opcodes, `IsSingleScalar` should be the only source used to decide whether a VPInstruction produces a scalar value, with convertToSingleScalar being the only place where we convert to SingleScalar explicitly.

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