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

JinGu Kang via cfe-dev cfe-dev at lists.llvm.org
Fri Jun 7 11:33:42 PDT 2019


Hi Richard,

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

I guess we can use 'byval' for parameter passing and 'sret' for return value. It means that we can use stack for the ABI and the stack could be allocated by dynamic alloc. As you know, CLANG has Target ABI Interface and I guess we can generate the attributes with the interface.

Regards,
JinGu Kang

________________________________
From: Richard Sandiford <richard.sandiford at arm.com>
Sent: 07 June 2019 18:33
To: JinGu Kang
Cc: cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] RFC: Adding vscale vector types to C and C++

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190607/96cc3d9d/attachment.html>


More information about the cfe-dev mailing list