Draft JEP: Vector API (original) (raw)

Paul Sandoz 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: Hi,

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.

Paul.

More information about the jdk-dev mailing list