[llvm-dev] [RFC][SVE] Supporting SIMD instruction sets with variable vector lengths

[Bruce Hoult via llvm-dev]

On Mon, Jul 30, 2018 at 1:12 PM, Renato Golin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> The worry here is not within each instruction but across instructions.
> SVE (and I think RISC-V) allow register size to be dynamically set.
>
> For example, on the same machine, it may be 256 for one process and
> 512 for another (for example, to save power).
>
> But the change is via a system register, so in theory, anyone can
> write an inline asm in the beginning of a function and change the
> vector length to whatever they want.
>
> Worst still, people can do that inside loops, or in a tail loop,
> thinking it's a good idea (or this is a Cray machine :).
>
> AFAIK, the interface for changing the register length will not be
> exposed programmatically, so in theory, we should not worry about it.
> Any inline asm hack can be considered out of scope / user error.
>
> However, Hal's concern seems to be that, in the event of anyone
> planning to add it to their APIs, we need to make sure the proposed
> semantics can cope with it (do we need to update the predicates again?
> what will vscale mean, then and when?).
>
> If not, we may have to enforce that this will not come to pass in its
> current form. In this case, changing it later will require *a lot*
> more effort than doing it now.
>
> So, it would be good to get a clear response from the two fronts (SVE
> and RISC-V) about the future intention to expose that or not.
>

Some characteristics of how I believe RISC-V vectors will or could end up:

- the user's data is stored only in normal C "arrays" (which of course can
mean a pointer into the middle of some arbitrary chunk of memory)

- vector register types will be used only within a loop in a single
user-written function. There is no way to pass a vector variable from one
function to another -- there is no effect on ABI.

- there will be some vector intrinsic functions such as trancendentals.
They will use a different, private ABI used only by the compiler and
implemented only in the runtime library. They will probably use the
alternate link register (x5 instead of x1) and will be totally not miscible
with normal functions.

- even within a single function, different loops may have different maximum
vector length, depending on how many vector registers are required and of
what element types (all vectors in a given loop have the same number of
elements).

- the active vector length can change from iteration to iteration of a
loop. In particular, it can be less on the final iteration to deal with
tails.

- the active vector length is set at the head of each iteration of a loop
by the program telling the hardware how many elements are left (possibly
thousands or millions) and the hardware saying "you can have 17 this time"

- (maybe) the active vector length can become shorter during execution of a
loop iteration as a side effect of a vector load or store getting a
protection error and loading/storing only up to the protection boundary. In
this case an actual trap will be taken only if the first element of the
vector causes the problem. Different micro-architectures might handle this
differently. It should be a rare event. An interrupt or task switch during
execution of a vector loop may cause the active vector length to become
zero for that iteration.


So, this is quite different in detail to ARM's SVE but it should be able to
use the same type system. The main differences are probably that they seem
to intend to be able to pass vector types from one function to another --
but their vector length is fixed for any given processor (or process?).
RISC-V loops may need to query the active vector length at the end of each
loop iteration. That's a different instruction that needs to be emitted,
but has no effect on the type system.

>From the point of view of the type system, I think RISC-V is a subset of
SVE, as there is no need to pass vectors between functions and no effect on
the ABI.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180730/5bbc5674/attachment.html>