Re: RFC: C extension to support variable-length vector types

[Richard Sandiford <richard dot sandiford at arm dot com>]

Hi Joseph,

Thanks for the quick feedback.

Joseph Myers <joseph@codesourcery.com> writes:
> On Wed, 2 Aug 2017, Richard Sandiford wrote:
>
>>   (1) Does the approach seem reasonable?
>> 
>>   (2) Would it be acceptable in principle to add this extension to the
>>       GCC C frontend (only enabled where necessary)?
>> 
>>   (3) Should we submit this to the standards committee?
>
> I think this only makes sense for WG14 in the context of a proposed 
> standard feature that would use the new type properties.
>
> The CPLEX group, having produced the first draft TS 21938-1 (Extensions 
> for parallel programming: Thread-based parallelism), may go on to other 
> related work including SIMD-based parallelism.  That might be the natural 
> context for proposals related to vector types, both fixed-size and 
> variable-size (see the discussion on the CPLEX list in June 2013, 
> especially <http://www.open-std.org/pipermail/cplex/2013-June/000018.html> 
> regarding types for native vector length rather than fixed vector length.  
> (Or some kind of vector proposal could be made directly for C2x, given the 
> widespread implementation experience with vector types.)
>
> I don't see how this proposal deals with initialization for such types 
> (either by disallowing it, or by providing a suitable way to initialize 
> them).  A fixed-size vector can be initialized with a brace-enclosed 
> initializer.  But if you use a brace-enclosed initializer for a variable 
> (with automatic storage duration) with one of these types, the compiler 
> can't tell if the size is large enough at compile time.  You allow 
> compound literals and initialization because you want to allow aggregates 
> of such types to be initialized, but that leaves unresolved the question 
> of what's valid for initializing the vectors themselves.

Yeah, sorry, I forgot to say that types like svuint8_t are opaque
built-in types.  They aren't vector types in the sense of the GNU
vector extensions (or other such extensions).  This means that the
only valid use of compound literals for vector types is:

    (sv<base>_t) { x }

where x also has type sv<base>_t.  Obviously this case isn't useful;
it's only the aggregate case that's useful.

The ACLE types are only intended to be used with the associated
intrinsics.  There are intrinsics for creating vectors from scalars,
loading from scalars, storing to scalars, reinterpreting one type as
another, etc.

> (The lack of a size from sizeof means memset and memcpy can't readily be 
> used for initialization either; likewise e.g. reading data from a file 
> into such a variable.  Presumably you have other extensions to cover such 
> things?)

The idea is that the vector types would only be used for working data
(i.e. data that's intended to be stored in registers where possible).
Longer-term data would be stored out to arrays.  So things like memcpy,
memset and file operations would be done on arrays as normal.

Thanks,
Richard