[vector] ARM SVE

[Paul Sandoz]

> On Mar 1, 2018, at 12:59 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> 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.
> 

Yes, currently the Vector API is aiming to support explicit and generic shape coding.


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

Agreed.


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

So far i think we are doing ok but could do better for managing loop indexes, vector reshapes/casts (Adam has been rubbing up against these, they can be hard to reason about), and ensuring masks are supported in all relevant places. Feedback greatly appreciated!

Paul.