RFR: 8318650: Optimized subword gather for x86 targets. [v2]

[Xiaohong Gong]

On Fri, 27 Oct 2023 05:09:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 3062:
>> 
>>> 3060:         // Constant folding should sweep out following conditonal logic.
>>> 3061:         if (isp.length() > IntVector.SPECIES_PREFERRED.length()) {
>>> 3062:             lsp = IntVector.SPECIES_PREFERRED;
>> 
>> What happens if the needed index vector length is larger that the max vector length of int type? 
>> For example, byte vectors with `SPECIES_128`, may needs an index vector with `IntVector.SPECIES_512` species? And on some architectures like NEON, or SVE with 128-bit max vector size, the preferred species is only `SPECIES_128`.
>
> For x86 backend implementation we emit a gather loop hence index species is not used for sub-word, I am performing the index out of bound in a loop which operate a max integer vector granularity supported by target.
> https://github.com/openjdk/jdk/pull/16354/files#diff-13cc2d6ec18e487ddae05cda671bdb6bb7ffd42ff7bc51a2e00c8c5e622bd55dR3641
> 
> Because there is cap on max integral vector size, thus for targets supporting direct sub-word gather instruction will have to emit an instruction sequence comprising of partial indexMap loads into integral vectors and issue multiple gather operations.

I see, thanks for the explanation! It's different from SVE, which the index should be an int vector with the same length of the target vector.  We have to generate the index vectors. So the array length check to the given index map is necessary in java side.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16354#discussion_r1374215257