Discussion of ABI will be useful too - thanks for raising it.

Is array by-value abi distinct from vector type mangling?
Such as this cxx-abi issue:
"Add vector type mangling (as discussed on the IA-64 reflector in 2009) #41"
https://github.com/itanium-cxx-abi/cxx-abi/issues
mentions the GNU vector_size attribute and the various Clang versions
(aside, I notice that Clang allows odd-sized vectors, GCC only factor-of-2.)

Then there's AArch62 existing practice:
Vector Function Application Binary Interface Specification for AArch64
https://developer.arm.com/documentation/101129/latest
Which includes VLA "vector-length agnostic" abi

There must be more implementation experience to gather,
both from earlier HPC-oriented vector processing
and from the rise of ML array and tensor processing.




On Tue, Aug 3, 2021 at 1:44 PM will wray <wjwray_at_[hidden]> wrote:

> Thanks Joseph,
>
> On Mon, Aug 2, 2021 at 12:51 PM Joseph Myers <joseph_at_[hidden]>
> wrote:
>
>> ... key questions to consider for C would include VLA issues
>> (note that initializers aren't allowed for VLAs at present)
>
>
> For VLA, it'd be useful to allow = {} in initialization and assignment.
>
> Same-type vla = vla seems straightforward too
> (same-size implied by same variably-modified type).
>
> Returning VLA by-value could be implementable in cases
> where the caller knows the size of the return array.
> In particular if the output is the same size as an input:
>
> // Fixed size array[4] -> array[4] function
> float array_function( float (*in)[4] ) [4]
> {
> return { f((*in)[0]), f((*in)[1]) ... ) };
> }
>
> // Variable size array[n] -> array[n] function
> float VLA_function( int n, float (*in)[n] ) [n] // ?
> {
> float out[n];
> for (int i = 0; i != n; ++i ) { out[i] = f((*in)[i]); }
> return out;
> }
>
> ? Is the argument 'n' in scope for the trailing [n] return size ?
>
> True, data-dependent, variable-size return-by-value is another thing.
>
>
>
> On Mon, Aug 2, 2021 at 1:55 PM Aaron Ballman via Liaison <
> liaison_at_[hidden]> wrote:
>
>> On Mon, Aug 2, 2021 at 12:51 PM Joseph Myers <joseph_at_[hidden]>
>> wrote:
>> >
>> > On Mon, 2 Aug 2021, Aaron Ballman via Liaison wrote:
>> >
>> > > I spoke with Lu Hongjiu (Intel's rep on psABI matters) internally
>> > > about psABI changes and his determination was that no psABI changes
>> > > were needed to support _BitInt because they aligned with existing
>> > > calling conventions.
>> >
>> > That's not correct. It's a new type, not mentioned in the existing
>> psABI
>> > documents, so it needs to be added to that document, just like other new
>> > types.
>> >
>> > > "With _BitInt(N) types align with existing calling conventions. They
>> > > have the same size and alignment as the smallest basic type that can
>> > > contain them. Types that are larger than __int64_t are conceptually
>> > > treated as struct of register size chunks. The number of chunks is the
>> > > smallest number that can contain the type. there is no need for psABI
>> > > change."
>> >
>> > The above description is a starting point for what goes in psABI
>> > documents, but it's not sufficient by itself. For example: are bits
>> > beyond the width of the _BitInt value but within the width of the
>> smallest
>> > basic type containing it required (for argument passing and return, or
>> for
>> > that matter for objects of the type in memory) to be
>> > sign-or-zero-extended, or may they take unspecified values? What about
>> > bits between the width of the smallest basic type containing it and the
>> > register-sized container? And likewise for the high word of
>> > larger-than-register _BitInt values?
>> >
>> > These are exactly the sort of issues that need to be considered in psABI
>> > groups for each architecture. The well-known
>> > https://bugs.llvm.org/show_bug.cgi?id=12207 and
>> > https://bugs.llvm.org/show_bug.cgi?id=44228 concerning sign and zero
>> > extension of narrower-than-register types illustrate the importance of
>> > getting such issues specified explicitly in psABI documents.
>>
>> Thank you for this, Joseph! I've passed along this information to HJ
>> to hopefully restart the discussions.
>>
>> ~Aaron
>>
>> >
>> > --
>> > Joseph S. Myers
>> > joseph_at_[hidden]
>> _______________________________________________
>> Liaison mailing list
>> Liaison_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
>> Link to this post: http://lists.isocpp.org/liaison/2021/08/0656.php
>>
>