Draft JEP: Vector API
paul.sandoz at oracle.com
Thu Apr 12 15:37:52 UTC 2018
> On Apr 11, 2018, at 7:50 PM, Ningsheng Jian <ningsheng.jian at linaro.org> wrote:
> Hi Paul,
> On 12 April 2018 at 08:31, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> Expanding a little further on shapes.
>> After some more thought i have my doubts that an explicit preferred shape is required. Vector computations can be written generic to shape and there is no need to expose a public type for a preferred shape (however, for optimal code generation the generic computations need to get inlined). Hiding the preferred shape behind a wildcard gives more flexibility since an existing public shape could be reused (as is the case right now), or something private, which might be the case for ARM SVE.
> Yes, I agree. That will make the application code more portable.
>> Speculating for ARM SVE i could imagine a single concrete implementation associated with a private preferred platform shape (the bit size and length methods would need to be made intrinsic so as to return constant values). It's probably not optimal to pre-generate given the bit size is platform specific (IIRC it can vary from 128 to 2048 bits in powers of 2).
> It's 128 to 2048, multiply of 128 :-)
Ah yes, thanks for correcting me. This makes it even more inappropriate to pre-generate shapes for all possible supported sizes. I anticipate we only require one such pre-generated implementation for ARM SVE that does not hard code the vector size.
More information about the jdk-dev