RFR: 8367292: VectorAPI: Optimize VectorMask.fromLong/toLong() for SVE [v3]
    Xiaohong Gong 
    xgong at openjdk.org
       
    Mon Oct 27 02:41:07 UTC 2025
    
    
  
On Fri, 24 Oct 2025 13:47:26 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:
>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename the matcher function and fix comment issue
>
> 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.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27481#discussion_r2464294733
    
    
More information about the hotspot-compiler-dev
mailing list