This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On August 3, 2017 5:32:40 PM GMT+02:00, Torvald Riegel <> wrote:
>On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote:
>> Torvald Riegel <> 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 ?
>> 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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]