[llvm-dev] Adding support for vscale

[Jacob Lifshay via llvm-dev]

On Tue, Oct 1, 2019, 00:08 Robin Kruppe <robin.kruppe at gmail.com> wrote:

> Hello Jacob and Luke,
>
> First off, even if a dynamically changing vscale was truly necessary for
> RVV or SV, this thread would be far too late to raise the question. That
> vscale is constant -- that the number of elements in a scalable vector does
> not change during program execution -- is baked into the accepted scalable
> vector type proposal from top to bottom and in fact was one of the
> conditions for its acceptance (runtime-variable type sizes create many more
> headaches which nobody has worked out how to solve to a satisfactory degree
> in the context of LLVM). *This* thread is just about whether vscale should
> be exposed to programs in the form of a Constant or as an intrinsic which
> always returns the same value during one program execution.
>
> Luckily, this is not a problem for RVV. I do not know anything about this
> "SV" extension you are working on so I cannot comment on that, but I'll
> sketch the reasons for why it's not an issue with RVV and maybe that helps
> you with SV too. As mentioned above, this is tangential to the focus of
> this thread, so if you want to discuss further I'd prefer you do that in a
> new thread.
>
> The dynamically-changing VL is a kind of predication in that it limits
> processing to a subset of lanes, and like masks it can just be another SSA
> value that is an input to the computations it affects. You may be aware of
> Simon Moll's vector predication (previously: explicit vector length)
> proposal which does just that. In contrast, the vscale concept is more
> about how many elements a vector register contains, regardless of whether
> some operations process only a subset of them. In RVV terms that means it's
> related not to VL but more to VBITS, which is indeed a constant (and has
> been for many months).
>
> The only dynamic thing about "how many elements are there in a vector
> register" is that varying the width of the elements (8b, 16b, etc.) and the
> length multiplier (grouping together 1/2/4/8 registers) causes a
> predictable, relative increase or decrease (x2, x8, x0.5, etc.)  of the
> number of elements, regardless of the specific value of VBITS. But this is
> perfectly compatible with a constant vscale because vscale only is the
> unknown-at-compile-time *factor* in the size of a scalable vector type.
> Varying the other components, the compile-time-constant factor and the
> element type, results in scalable vectors with different *relative* sizes
> in exactly the same way we need to handle RVV's element width and LMUL
> concepts. For example <vscale x 4 x i16> has four times as many elements
> and twice as many bits as <vscale x 1 x i32>, so it captures the
> distinction between a SEW=16,LMUL=2 vtype setting and a SEW=32,LMUL=1 vtype
> setting.
>

Ah, ok. So vscale is basically calculated based off of the type and vlmax
rather than being VL.

SV works mostly like that except it supports more than one vlmax, since
vlmax is derived from the number of contiguous int/fp registers that the
register allocator assigns to that particular vector (which can be part of
the vector type rather than leaving it entirely up to the register
allocator).

So, SV may not be able to use scalable vectors directly but may work better
with fixed-length vectors where all the vector ops have a VL parameter
there. perhaps it could use scalable vectors then translate to fixed-length
vectors + VL.

Jacob Lifshay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191001/205c4a40/attachment.html>