This is the mail archive of the
mailing list for the GCC project.
Re: RFC: C extension to support variable-length vector types
On August 3, 2017 5:32:40 PM GMT+02:00, Torvald Riegel <firstname.lastname@example.org> wrote:
>On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote:
>> Torvald Riegel <email@example.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
>> >> 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
>> > be good to have the standards committees review this. I doubt you
>> > 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
>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.
>> 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
>> That's an important use case for us, and I think there's always going
>> be a need for it alongside generic SIMD and parallel-programming
>> (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
>C is more restricted and thus has to use language extensions more
>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?