<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 6, 2019, 19:23 Luke Kenneth Casson Leighton via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">lkcl added a comment.<br>
<br>
In D57504#1387621 <<a href="https://reviews.llvm.org/D57504#1387621" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D57504#1387621</a>>, @simoll wrote:<br>
<br>
> In D57504#1386491 <<a href="https://reviews.llvm.org/D57504#1386491" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D57504#1386491</a>>, @lkcl wrote:<br>
><br>
> > remember that both RVV and SV support the exact same vscale (variable-length multiples of elements) concept.<br>
><br>
><br>
> 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).<br></blockquote></div></div><div dir="auto">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.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
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.<br></blockquote></div></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Mask registers consist of a single scalar integer register, which limits the maximum VL to 64 since there are only 64 bits.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D57504/new/" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D57504/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D57504" rel="noreferrer noreferrer" target="_blank">https://reviews.llvm.org/D57504</a><br>
<br>
<br>
<br>
</blockquote></div></div></div>