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