[vectorIntrinsics+mask] RFR: 8264563: Add masked vector intrinsics for binary/store operations [v5]

Vladimir Ivanov vlivanov at openjdk.java.net
Wed Apr 21 09:27:14 UTC 2021


On Tue, 13 Apr 2021 08:00:23 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Hi, this is the basic masking support PR for Vector API mask operations on platforms like SVE/AVX-512. The main codes are from [1], which contains:
>> 
>> - The predicate register allocation for Arm SVE, and vector mask type definition.
>> - The basic optimization for parts of the mask operations with masking feature. It contains:   
>>  
>>   1. Vector API java implementation changes for masked binary/store.
>>   2. C2 compiler mid-end changes, including new vector intrinsics implementation and mask IRs.
>> 
>> Note that for easier discussion, this PR only provides the changes for limited masked operations (e.g. binary/store) and the mask generations (e.g. load/compare/maskAll). We will continue working on the following missing parts:
>> 
>> - Mask support for other operations (unary,ternary,reduction,load,etc.)
>> - More mask IRs implementation (and/or/xor, toVector, allTrue, anyTrue, trueCount, eq, etc)
>> - Vector boxing/unboxing support for mask type (deoptimization support for predicate registers)
>> 
>> Also note that this PR doesn't contain any backend implementations. So the blend pattern will be generated as before. Regarding to the AArch64 SVE backend support, we will create a separate PR based on this one in future.
>>   
>> [1] https://github.com/openjdk/panama-vector/pull/40
>> 
>> See more details from:
>> http://cr.openjdk.java.net/~xgong/rfr/mask/Vector%20API%20masking%20support%20proposal%20for%20Arm%20SVE.pdf
>> http://cr.openjdk.java.net/~xgong/rfr/mask/VectorAPI%20masking%20support.pdf
>> 
>> Any suggestions and discussions are welcome! Thanks a lot!
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove null checking for the mask argument in API implementation

I have one request: `m == null` should be part of internal agreement between JVM and JDK and completely hidden from users. It means that all non-masked operations (when/if they are migrated to masked intrinsics) should pass `null` constant as a mask and all masked operations should perform the null check to ensure mask value is always non-null and clearly communicate that to JITs.

I think it is important because it is a prerequisite for successful intrinsification: unless C2 can't definitely say whether the mask is `null` or non-`null`, it can't make the decision how to implement the operation. So, we should be cautious about possible inlining and profile pollution effects and ensure that all usages of `VectorSupport::binaryMaskedOp()/storeMasked()` provide enough information for C2 to detect proper operation mode.

src/hotspot/share/classfile/vmIntrinsics.hpp line 821:

> 819:    do_name(vector_binary_op_name,     "binaryOp")                                                                                              \
> 820:                                                                                                                                                \
> 821:   do_intrinsic(_VectorBinaryMaskOp, jdk_internal_vm_vector_VectorSupport, vector_binary_mask_op_name, vector_binary_mask_op_sig, F_S)          \

Should it be named `VectorBinaryMaskedOp`?

src/hotspot/share/opto/library_call.hpp line 313:

> 311:   // Vector API support
> 312:   bool inline_vector_nary_operation(int n);
> 313:   bool inline_vector_nary_mask_operation(int n);

Should it be named `inline_vector_nary_masked_operation()`?

src/hotspot/share/opto/matcher.hpp line 320:

> 318:   static const bool match_rule_supported_vector(int opcode, int vlen, BasicType bt);
> 319: 
> 320:   static const bool match_rule_supported_masked_vector(int opcode, int vlen, BasicType bt);

IMO `Matcher::match_rule_supported_vector_masked()` is a better option.

src/hotspot/share/opto/vectornode.cpp line 755:

> 753:     }
> 754:   }
> 755:   return StoreNode::Ideal(phase, can_reshape);

Can you elaborate, please, why this change is needed?

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

PR: https://git.openjdk.java.net/panama-vector/pull/57


More information about the panama-dev mailing list