[PATCH] D57504: RFC: EVL Prototype & Roadmap for vector predication in LLVM

[David Greene via Phabricator via llvm-commits]

greened added a comment.

In D57504#1388300 <https://reviews.llvm.org/D57504#1388300>, @lkcl wrote:

> In D57504#1387621 <https://reviews.llvm.org/D57504#1387621>, @simoll wrote:
>
> > We've already agreed that the unit of the vlen parameter is just the element type (that is the sub-vector element type in the vector-of-subvector interpretation of scalable types).
>
>
> appreciated, simoll, apologies for giving the false impression that there was disagreement with that: i remained silent previously, as i agreed with the conclusion / logic, that vlen should match the full total number elements even on sub-vectors.
>
> i *believe* (robin, can you clarify / confirm?) that robin may have been disagreeing on predicate masks, i.e. i *believe* that robin may be requesting that predicate masks *also* match the elements one-for-one.  in SV, as jacob expressed: we definitely feel that an option for predicates to be on the *sub-vectors* i.e. len(predicate_mask) == VL/VSCALE (*not* just VL) would result in much more optimal SV-assembler being generated.


For completeness, I just want to add the suggestion I made on the mailing list that subvector types could be expressed as `<scalable 1 x <3 x float>>`, where the vector element type is itself a vector.  Masks operating in terms of subvectors would be `<scalable 1 x <3 x i1>>`.  These are really matrix types.  :)  Intrinsics could be provided for both the traditional flat vectors and the vector-as-vector-element types.

ARM's SVE proposal interprets `<scalable n x type>` as a flat vector and I think it would be confusing to change the interpretation of that, even if it is target-dependent.  Separate concepts should have separate types.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D57504