RFR: 8351623: VectorAPI: Add SVE implementation of subword gather load operation [v6]
Xiaohong Gong
xgong at openjdk.org
Wed Nov 12 01:50:11 UTC 2025
On Mon, 10 Nov 2025 23:38:55 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:
> > and similarly move vector slice operations to the compiler
>
> Yes, you have to slice the mask, whether it be represented as a mask/predicate register or as a vector. There's no way around that and we have to deal with the current limitations in hardware. As a further compromise we can in Java convert the mask to a vector and rearrange it, then pass the vector representation of the mask to the scatter/gather intrinsic. Then the intrinsic can if it chooses convert it back to a mask/predicate register if that is the best form.
Yes, converting mask to vector will be the way to resolve. Do you think it's better that defining a private VectorMask function for the slice operation? The function could be implemented with corresponding vector slice APIs. Although this function is not friendly to SVE performance, it wins on unifying the implementation.
>
> IIUC we have agreed for non-masked subword scatter/gather to compose by parts using the intrinsic. That seems good, and it looks like we can do the same for masked subword scatter/gather, as above, but it may not be the most efficient for the platform.
>
> Do you have any use cases for mask subword scatter/gather? Given the lack of underlying hardware support it seems focusing on getting the non-masked version working well, and the masked version working ok is a pragmatic way forward.
Currently, I do not have specific use cases for masked subword gather or scatter operations. However, I would like to ensure support for these APIs on SVE in case they become relevant for future Java workloads. However, compared to having no intrinsic support at all, using intrinsified APIs—even if not fully optimized—can still significantly improve performance, right?
BTW, I agree that focusing only on the non-masked version would certainly simplify the implementation a lot.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/26236#issuecomment-3519515914
More information about the hotspot-compiler-dev
mailing list