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

[Jacob Lifshay via llvm-commits]

On Wed, Feb 6, 2019, 19:23 Luke Kenneth Casson Leighton via Phabricator <
reviews at reviews.llvm.org> wrote:

> lkcl added a comment.
>
> In D57504#1387621 <https://reviews.llvm.org/D57504#1387621>, @simoll
> wrote:
>
> > In D57504#1386491 <https://reviews.llvm.org/D57504#1386491>, @lkcl
> wrote:
> >
> > > remember that both RVV and SV support the exact same vscale
> (variable-length multiples of elements) concept.
> >
> >
> > 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).
>
In that case, we'll just have to rededuce the correct vlen for
vector-of-subvector cases as, in our design (SVprefix), the VL register
counts the number of subvectors, not the number of subvector elements. This
seems more logical to me as then VL is the number of instances of the
pre-vectorization code that is run per post-vectorization iteration. I hope
the design will accommodate arithmetic on VL, post-setvl, to allow for this.

>
>
> 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.
>
An explanation, for those who aren't following the libre-riscv-dev mailing
list: there are 2 different isa designs we are thinking about: SVcsr (the
original SV) that Luke proposed, and SVprefix that I proposed.

SVcsr is based on having the base scalar ISA modified by setting CSR
registers that change certain registers to refer to a vector made from a
range of registers instead, thereby vectorizing the instruction. This
allows for adding vectorization while reusing the original instruction
encodings. SVcsr currently supports subvectors in the form of a REMAP field
in the CSRs, which is basically support for a operand being
matrix-transposed, with no modification to VL or predication.

SVprefix is based on adding a new 48-bit instruction encoding that contains
a 32-bit instruction that allows specification of vector/scalar operations.
SVprefix supports a per-instruction VL-multiplier (VL-mul) that change the
instruction to operate on VL short vectors that are each VL-mul elements
long, with one mask bit per short vector.

We are in the process of fleshing out the SVprefix proposal so that we can
decide wether to use SVprefix, SVcsr, or some combination thereof.

Both of the proposals extend both the integer and fp register files to 128
64-bit registers, and vector operands consist of a consecutive range of
scalar registers specified by the start register with the length specified
by VL scaled to account for wider/narrower types.

Mask registers consist of a single scalar integer register, which limits
the maximum VL to 64 since there are only 64 bits.

>
> 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.
>
>
> Repository:
>   rL LLVM
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D57504/new/
>
> https://reviews.llvm.org/D57504
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190206/45d458b1/attachment.html>