On August 3, 2017 5:51:35 PM GMT+02:00, Richard Biener <richard.guent...@gmail.com> wrote: >On August 3, 2017 5:32:40 PM GMT+02:00, Torvald Riegel ><trie...@redhat.com> wrote: >>On Wed, 2017-08-02 at 17:59 +0100, Richard Sandiford wrote: >>> Torvald Riegel <trie...@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?
