[vector] ARM SVE

[Andrew Haley]

On 28/02/18 01:33, Paul Sandoz wrote:

> For SVE It makes less sense to refer to explicit shapes we currently
> have now, the implementations are far less useful for any cross
> x86/ARM CPU platform code, and in general the guidance is where
> possible to code algorithms in a shape agnostic manner.
> 
> Might it be useful to expose such a shape explicitly as a type, such
> as Shapes.SPreferred? does this imply in the long run that shape is
> not required as the sweet spot is shape agnostic code?

I would hope so.  On the one had we want to be as efficient as
possible, and that must to some extent mean exposing hardware details,
but on the other hand we want hardware-independent high-level-language
abstractions.

> I suspect for the latter question it might be too early to answer
> properly. For the former question it seems quite possible to expose
> such a shape if more preferable to using the wild card.
> 
> For shape agnostic code i think we will require some helper methods
> to manage the tail of elements that do full up to the preferred
> vector size. SVE has some interesting instructions for managing this
> aspect and masks (termed predicates) are fundamental to this rather
> than optional as in AVX. This might affect the efficiency of code
> produced on a SVE platform. We might need to explore functional
> loopy code if we can side-step the profile polution (i.e. version
> the generated loop methods per the vector kernels). SVE also has
> interesting support for data dependent loops where a vector can be
> loaded where some lanes silently fault until accessed (speculative
> access [*]).

Thanks for looking at this.  It's very useful to have a look now at
our core assumptions about what a vector might look like.

It's unfortunate that SVE hardware is still a little way away, but if
we can write shape-agnostic code we should.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671