RFR: 8367292: VectorAPI: Optimize VectorMask.fromLong/toLong() for SVE [v3]

Emanuel Peter epeter at openjdk.org
Tue Oct 28 09:45:30 UTC 2025


On Mon, 27 Oct 2025 02:38:44 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 2548:
>> 
>>> 2546:       }
>>> 2547:       // VectorMaskToLongNode requires the input is either a mask or a vector with BOOLEAN type.
>>> 2548:       if (Matcher::mask_op_uses_packed_vector(Op_VectorMaskToLong, opd->bottom_type()->is_vect())) {
>> 
>> So without this patch, it'd generate `VectorMaskToLong -> URShiftLNode -> AndLNode` (as the earlier `if` condition would have been false) and in the backend, the implementation for `VectorMaskToLong` contains code to convert the mask in a predicate to a packed vector (followed by the actual `VectorMaskToLong` related code). With this patch, it now generates `VectorStoreMaskNode -> VectorMaskToLong -> URShiftLNode ... `(the backend implementation is now separated at the IR level).
>> Does the major performance uplift come from this Ideal optimization - `VectorMaskToLongNode::Ideal_MaskAll()` where the `VectorStoreMaskNode` gets optimized away?
>
> Yes, the IR changes you pointed above is right. 
> 
> The major performance uplift comes from the existing optimization  of `VectorStoreMask (VectorLoadMask v) => v`. As you know, `VectorLoadMask` will be generated by some APIs like `VectorMask.fromArray()`. With this change, `VectorMask.fromLong()` also generates this IR. The mask conversions (V->P and P->V) between these APIs can be saved. 
> 
> Another performance uplift comes from the flexible vector register allocation. Before, the vector register is specified as the same for different instructions. But now, it depends on RA. In this case, it potentially breaks the un-expected  data-dependence across loop iterations.

@XiaohongGong If this is only about `VectorStoreMask (VectorLoadMask v) => v`, why not solve the issue with an `Ideal` optimization? Would that be an alternative?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27481#discussion_r2468764825


More information about the hotspot-compiler-dev mailing list