[llvm-dev] Adding support for vscale

[Robin Kruppe via llvm-dev]

On Wed, 2 Oct 2019 at 05:09, Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

>
> My general feeling on this then is that both RVV and SV should avoid using
> vscale.
>
> In the case of RVV, MVL is a hardware defined constant that is never
> *intended* to be known by applications. There's no published detection
> mechanism.  Loops are supposed to be designed to run a few more times on
> lower spec'd hardware.
>
> Robin, what's your thoughts there?
>

Software should be portable across different RVV implementations, in
particular across different values of the impl-defined constants VLEN,
ELEN, SLEN. But being portable does not mean software must never
mention these (and derived quantities such as vscale or, in the RVV spec,
VLMAX) at all, just that it has to work correctly no matter which value
they have. And in fact, there is a published (written out in the spec)
mechanism for obtaining VLMAX, which is directly related to VLEN (so you
can obtain VLEN with a little more arithmetic, though for most purposes
VLMAX is more useful): requesting the vector length of -1 (unsigned: 2^XLEN
- 1) is guaranteed to result in vl=VLMAX.

For regular strip-mined loops, the vsetvl instruction takes care of
everything so there's simply no need for the program to do this. But for
other tasks, it's required (i.e., you can't sensibly write the program
otherwise) and perfectly fine w.r.t. portability. One example is the stack
frame layout when there's any vectors on the stack (e.g. for spills), since
the vector stack slots must in general be large enough to hold a full
vector (= VLEN*LMUL bits). Granted, I don't think this or other examples
will normally occur in LLVM IR generated by a loop vectorizer, so vscale
will probably not occur very frequently in RVV. Nevertheless, there is
nothing inherently non-portable about it.

Regards
Robin

PS: I don't want to read too much into your repeated use of "MVL", but FWIW
the design of RVV has changed quite radically since "MVL" was last used in
any spec draft. If you haven't read any version since v0.6 (~ December
2018) with a "clean slate", may I suggest you do that when you find the
time? You can find the latest draft at
https://github.com/riscv/riscv-v-spec/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191002/92906cba/attachment.html>