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

[Torvald Riegel <triegel at redhat dot com>]

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?

> 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?