[cfe-dev] RFC: Adding vscale vector types to C and C++

[Richard Sandiford via cfe-dev]

JinGu Kang <jingu at codeplay.com> writes:

>> These are all negative reasons for (1) being the best approach.
>> A more positive justification is that (1) seems to meet the requirements
>> in the most efficient way possible.  The vectors can use their natural
>> (native) representation, and the type system prevents uses that would
>> make that representation problematic.
>
>> Also, the approach of starting with very restricted types and then
>> specifically allowing certain things should be more future-proof
>> and interact better with other (unseen) language extensions.  By default,
>> any language extension would treat the new types like other incomplete
>> types and choose conservatively-correct behavior.  It would then be
>> possible to relax the rules if this default behavior turns out to be
>> too restrictive.
>
> I wondered we can define the restriction of this type well on C/C++ standard.
> From my personal opinion, this RFC suggests clear concept. I am +1000 for (1).
> Additionally, for the variable length array, I agree with your opinion. One
> thing I would like to mention is that we could use 'dynamic_alloc' for the
> local variable of this type like other variable sized objects. If we use it, I
> guess we don't need to change backend code.

Yeah, dynamic allocation works well for local variables, and for example
we'd emit the equivalent of:

    %var = alloca <vscale x 4 x i32>

for:

    svint32_t var;

But having the vscale LLVM type is important for function interfaces,
where we need to able to pass and return vectors by value.

Thanks,
Richard