RFR: 8367292: VectorAPI: Optimize VectorMask.fromLong/toLong() for SVE [v2]
Xiaohong Gong
xgong at openjdk.org
Fri Oct 24 02:04:05 UTC 2025
On Thu, 23 Oct 2025 10:49:37 GMT, Emanuel Peter <epeter at openjdk.org> wrote:
> > VectorStoreMask is a opposite operation of VectorLoadMask. We can treat it as a layout conversion for a vector mask. It is used to convert a vector mask (either a unpacked vector or a predicate) to a packed vector status (i.e. 8-bit element size). Because, in Java API, elements of a VectorMask is stored into a boolean array.
>
> Thanks for the explanation! So it really only does the conversion, right? And no loading / storing? If that is true, we may want to rename them to `ConvPredicate2PackedVectorMaskNode`, or alike. What do you think?
Yes, it just finished the layout conversion for a mask, without no loading/storing.
These two IRs are frequently used in Vector mask relative operations in C2 mid-end and each backend, such as load/store/VectorBox/VectorUnbox and object re-materialize during deoptimization, and so on. They were added at the beginning support of API I think. Renaming is not an easy work.
The main function of these two IRs are the conversion between different mask layout from compiler and java API:
1) To load a vector mask from memory (a boolean array), it needs to load the values into a boolean array with `LoadVectorNode`, and then convert the boolean vector to a data vector with `VectorLoadMask`.
2) To store a vector mask from compiler to a memory, it needs to convert the data vector to a boolean vector with `VectorStoreMask`, and then store the boolean vector to memory with `StoreVectorNode`.
Hence, these two APIs are a part of `VectorMask.fromArray()/intoArray()` relatively. Although they really do not any memory access operation. If we have a better name for these two IRs, I think that would be another topic that we can revisit with a separate thread. WDYT?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27481#discussion_r2458378440
More information about the hotspot-compiler-dev
mailing list