[vector] ARM SVE

[Paul Sandoz]

> On Mar 1, 2018, at 1:12 AM, Roland Westrelin <rwestrel at redhat.com> wrote:
> 
> 
> Hi Paul,
> 
>> 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'm somewhat confused by this. Are you suggesting to expose
> Shapes.SPreferred as a way to help better take advantage of ARM SVE?

No, it would primarily be a way to express shape agnostic code without doing <S extends Shape> or <? extends Shape>. There is a method on vector (which will be updated to the following to fix a generic bug): 

  static <E, ?> Vector.Species<E> preferredSpeciesInstance(Class<E> c)

All vectors produced by that species will be of Vector<E, ?>

What if instead it was Vector<E, Shape.SPreferred> ?


> I thought the guideline/goal was, whether on x86 or other hardware, to
> write shape agnostic code anyway?
> 

Yes, what i wrote was a thought experiment, it leads to a possible realization in the long run that shape might not be needed. For now think it is and using type variables and wild cards seems ok for the moment.


> My understanding, also, was that shape agnostic code in the vector API
> is built on top of fixed size shapes. Those shapes are then what the
> JIT works with and where interfacing with the hardware is happening so
> exposing Shapes.SPreferred higher up wouldn't affect code generation.
> 

Yes, that was my assumption. The preferred shape size although not specified in the type system is fixed per the hardware so the JIT knows the size.


> What am I misunderstanding?
> 

Did my further explanation help?

Thanks,
Paul.