RFR: 8351623: VectorAPI: Add SVE implementation of subword gather load operation [v6]

[Paul Sandoz]

On Tue, 14 Oct 2025 07:04:28 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Add more comments for IRs and added method
>>  - Merge branch 'jdk:master' into JDK-8351623-sve
>>  - Merge 'jdk:master' into JDK-8351623-sve
>>  - Address review comments
>>  - Refine IR pattern and clean backend rules
>>  - Fix indentation issue and move the helper matcher method to header files
>>  - Merge branch jdk:master into JDK-8351623-sve
>>  - 8351623: VectorAPI: Add SVE implementation of subword gather load operation
>
> Hi @iwanowww , @PaulSandoz , @eme64 ,
> 
> Hope you’re doing well!
> 
> I’ve created a prototype that moves the implementation to the Java API level, as suggested (see: https://github.com/XiaohongGong/jdk/pull/8). This refactoring has resulted in significantly cleaner and more maintainable code. Thanks for your insightful feedback @iwanowww !
> 
> However, it also introduces new issues that we have to consider. The codegen might **not be optimal**. If we want to generate the optimal instruction sequence, we need more effort. 
> 
> Following is the details:
> 
> 1) We need a new API to cross-lane shift the lanes for a vector mask, which is used to extract different piece of a vector mask if the whole gather operation needs to be split.  Consider it has a `Vector.slice()` API which can implement such a function, I added a similar one for `VectorMask`. 
> 
>     There are two new issues that I need to address for this API:
>      -  SVE lacks a native instruction for such a mask operation. I have to convert it to a vector, call the Vector.slice(), and then convert back to a mask. Please note that the whole progress is **not SVE friendly**. The performance of such an API will have large gap on SVE compared with other arches.
>      - To generate a SVE optimal instruction, I have to do further IR transformation and optimize the pattern with match rule. I'm not sure whether the optimization will be common enough to be accepted in future.
>      
>     Do you have a better idea on the new added API? I'd like to avoid adding such a performance not friendly API, and the API might not be frequently used in real world.
> 
> 2) To make the interface uniform across-platforms, each API is defined as the same vector type of the target result, although we need to do separation and merging. However, as the SVE gather-load instruction works with int vector type, we need special handling in compiler IR-level.
> 
>    I'd like to extend `LoadVectorGather{,Masked}` with `mem_bt` to handle subword loads, adjust mask with cast/resize before and append vector cast/reinterpret after. Splitting into simple IRs make it possible for further IR-level optimization.  This might make the compiler IRs different across platforms like what it is in current PR.  Hence, the compiler change might not be so clean.  Does this make sense to you?
> 
> 3) Further compiler optimization is necessary to optimize out in-efficient instructions. This needs the combination of IR transformation and match rules. I think this might be more complex, an...

@XiaohongGong would it help if `loadWithMap` accepted a `part` number, identifying what part of the mask to use and identifying the part where the returned elements will be located, such that the returned vectors can be easily composed with logical or (as if merging).

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

PR Comment: https://git.openjdk.org/jdk/pull/26236#issuecomment-3403067724