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