RFC: C extension to support variable-length vector types

Richard Biener richard.guenther@gmail.com
Thu Aug 3 16:09:00 GMT 2017


On August 3, 2017 5:51:35 PM GMT+02:00, Richard Biener <richard.guenther@gmail.com> wrote:
>On August 3, 2017 5:32:40 PM GMT+02:00, Torvald Riegel
><triegel@redhat.com> wrote:
>>On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote:
>>> Torvald Riegel <triegel@redhat.com> writes:
>>> > On Wed, 2017-08-02 at 14:09 +0100, 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 hadn't have time to look at the proposal in detail.  I think it
>>would
>>> > be good to have the standards committees review this.  I doubt you
>>could
>>> > find consensus in the C++ for type system changes unless you have
>a
>>> > really good reason.  Have you considered how you could use the ARM
>>> > extensions from http://wg21.link/p0214r4 ?
>>> 
>>> Yeah, we've been following that proposal, but I don't think it helps
>>> as-is with SVE.  datapar<T> is "an array of target-specific size,
>>> with elements of type T, ..." and for SVE the natural
>target-specific
>>> size would be a runtime value.  The core language would still need
>to
>>> provide a way of creating that array.
>>
>>I think the actual data will have a size -- your proposal seems to try
>>to express a control structure (ie, SIMD / loop-like) by changing the
>>type system.  This seems odd to me.
>>Why can't you keep the underlying data have a size (ie, be an array),
>>and change your operations to work on arrays or slices of arrays? 
>That
>>won't help with automatic-storage-duration variables that one would
>>need
>>as temporaries, but perhaps it would be better to let programmers
>>declare these variables as large vectors and have the compiler figure
>>out what size they really need to be if only accessed through the SVE
>>operations as temporary storage?
>
>Btw., I did this once to represent constrained expressions on
>multi-dimensional arrays in SSA form.  There control (aka loop)
>structure was also implicit.  Google for 'middle-end array
>expressions'.  The C interface was builtins and VLAs.

So the point was that at the C source level the temporaries were simple scalars
And the middle-end uses the built-in functions as source/sinks to transform them accordingly.

So maybe scalars can be used for SVE as well.

Richard.

>Richard.
>
>>> Similarly to other vector architectures (including AdvSIMD), the SVE
>>> intrinsics and their types are more geared towards people who want
>>> to optimise specifically for SVE without having to resort to
>>assembly.
>>> That's an important use case for us, and I think there's always
>going
>>to
>>> be a need for it alongside generic SIMD and parallel-programming
>>models
>>> (which of course are a good thing to have too).
>>> 
>>> Being able to use SVE features from C is also important.  Not all
>>> projects are prepared to convert to C++.
>>
>>I'd doubt that the sizeless types would find consensus in the C++
>>committee.  The C committee may perhaps be more open to that, given
>>that
>>C is more restricted and thus has to use language extensions more
>>often.
>>
>>If they don't find uptake in ISO C/C++, this will always be a
>>vendor-specific thing.  You seem to say that this may be okay for you,
>>but are there enough non-library-implementer developers out there that
>>would use it to justify extending the type system?



More information about the Gcc mailing list