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

[David A. Greene via llvm-dev]

Graham Hunter via llvm-dev <llvm-dev at lists.llvm.org> writes:

>> Ok, now I understand what you're getting at.  A ConstantExpr would
>> encapsulate this computation.  We alreay have "non-static-constant"
>> values for ConstantExpr like sizeof and offsetof.  I would see
>> VScaleConstant in that same tradition.  In your struct example,
>> getSizeExpressionInBits would return:
>> 
>> add(mul(256, vscale), 64)
>> 
>> Does that satisfy your needs?
>
> Ah, I think the use of 'expression' in the name definitely confuses the issue then. This
> isn't for expressing the size in IR, where you would indeed just multiply by vscale and
> add any fixed-length size.

Ok, thanks for clarifying.  The use of "expression" is confusing.

> This is for the analysis code around the IR -- lots of code asks for the size of a Type in
> bits to determine what it can do to a Value with that type. Some of them are specific to
> scalar Types, like determining whether a sign/zero extend is needed. Others would
> apply to vector types (including scalable vectors), such as checking whether two
> Types have the exact same size so that a bitcast can be used instead of a more
> expensive operation like copying to memory and back to convert.

If this method returns two integers, how does LLVM interpret the
comparison?  If the return value is { <unscaled>, <scaled> } then how
do, say { 1024, 0 } and { 0, 128 } compare?  Doesn't it depend on the
vscale?  They could be the same size or not, depending on the target
characteristics.

Are bitcasts between scaled types and non-scaled types disallowed?  I
could certainly see an argument for disallowing it.  I could argue that
for bitcasting purposes that the unscaled and scaled parts would have to
exactly match in order to do a legal bitcast.  Is that the intent?

>> Is there anything about vscale or a scalable vector that requires a
>> minimum bit width?  For example, is this legal?
>> 
>> <scalable 1 x double>
>> 
>> I know it won't map to an SVE type.  I'm simply curious because
>> traditionally Cray machines defined vectors in terms of
>> machine-dependent "maxvl" with an element type, so with the above vscale
>> would == maxvl.  Not that we make any such things anymore.  But maybe
>> someone else does?
>
> That's legal in IR, yes, and we believe it should be usable to represent the vectors for
> RISC-V's 'V' extension. The main problem there is that they have a dynamic vector
> length within the loop so that they can perform the last iterations of a loop within vector
> registers when there's less than a full register worth of data remaining. SVE uses
> predication (masking) to achieve the same effect.
>
> For the 'V' extension, vscale would indeed correspond to 'maxvl', and I'm hoping that a
> 'setvl' intrinsic that provides a predicate will avoid the need for modelling a change in
> dynamic vector length -- reducing the vector length is effectively equivalent to an implied
> predicate on all operations. This avoids needing to add a token operand to all existing
> instructions that work on vector types.

Right.  In that way the RISC V method is very much like what the old
Cray machines did with the Vector Length register.

So in LLVM IR you would have "setvl" return a predicate and then apply
that predicate to operations using the current select method?  How does
instruction selection map that back onto a simple setvl + unpredicated
vector instructions?

For conditional code both vector length and masking must be taken into
account.  If "setvl" returns a predicate then that predicate would have
to be combined in some way with the conditional predicate (typically via
an AND operation in an IR that directly supports predicates).  Since
LLVM IR doesn't have predicates _per_se_, would it turn into nested
selects or something?  Untangling that in instruction selection seems
difficult but perhaps I'm missing something.

                                 -David