RFR: 8262355: Support for AVX-512 opmask register allocation. [v14]

[Ningsheng Jian]

On Sun, 21 Mar 2021 12:45:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> AVX-512 added 8 new 64 bit opmask registers[1] . These registers allow conditional execution and efficient merging of destination operands. At present cross instruction mask propagation is being done either using a GPR (e.g. vmask_gen patterns in x86.ad) or a vector register (for propagating results of a vector comparison or vector load mask operations).
>> 
>> This base patch extends the register allocator to support allocation of opmask registers. This will facilitate mask propagation across instructions and thus enable emitting efficient instruction sequence over X86 targets supporting AVX-512 feature.
>> 
>> We intend to build a robust optimization framework[2] based on this patch to emit optimized instruction sequence for masked/predicated vector operation for X86 targets supporting AVX-512. 
>> 
>> Please review and share your feedback.
>> 
>> Summary of changes:
>> 
>> 1) AD side changes: New register definitions, register classes, allocation classes, operand definitions and spill code handling for opmask registers.
>> 
>> 2) Runtime: Save/restoration for opmask registers in 32 and 64 bit JVM.
>>    a) For 64 bit JVM we were anyways reserving the space in the frame layout but earlier were not saving and restoring at designated offset(1088), hence no extra space overhead apart from save/restore cost.
>>    b) For 32 bit JVM: Additional 64 byte are allocated apart from FXSTORE area on the lines of storage for ZMM(16-31) and YMM-Hi bank. There are few regressions due to extra space allocation which we are investigating.
>> 
>> 3) Replacing all the hard-coded opmask references from macro-assembly routines: Pulling out the opmask occurrences all the way up to instruction pattern and adding an unbounded opmask operand for them. This exposes these operands to RA and scheduler; this will automatically facilitate spilling of live opmask registers across call sites.
>> 
>> 4) Register class initializations related to Op_RegVMask during matcher startup.
>> 
>> 5) Handling for mask generating node:  Currently VectorMaskGen node uses a GPR to propagate mask across mask generating DEF instruction to its USER instructions. There are other mask generating nodes like VectorCmpMask, VectorLoadMask which are not handled as the part of this patch. Conditional overriding of two routines, ideal_reg and bottom_type for mask generating IDEAL nodes and modifying the instruction patterns to have new opmask operands enables instruction selector to associate opmask register class with USE/DEF operands  for such MachNodes. This will constrain  the allocation set for these operands to opmask registers(K1-K7).
>> 
>> 6) Special handling for setting a flag in PhiNode during construction in case any of its incoming node is a mask generating node, this flag is then checked to return appropriate ideal_reg and bottom_type corresponding to an opmask registers.
>> 
>> [1] : Section 15.1.3 :  https://software.intel.com/content/www/us/en/develop/download/intel-64-and-ia-32-architectures-software-developers-manual-volume-1-basic-architecture.html
>> [2] : http://cr.openjdk.java.net/~jbhateja/avx512_masked_operation_optimization/AVX-512_RA_Opmask_Support_VectorMask_Optimizations.pdf
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8262355: Extending Type::isa_vect and Type::is_vect routines to TypeVectMask since its a valid vector type.

src/hotspot/share/opto/ifg.cpp line 506:

> 504:       const RegMask& rm = lrg.mask();
> 505:       if (rm.overlap(*Matcher::idealreg2regmask[Op_RegI]) ||
> 506:           rm.overlap(*Matcher::idealreg2regmask[Op_RegVMask])) {

For other ARCHs, Matcher::idealreg2regmask[Op_RegVMask] will be NULL.

src/hotspot/share/opto/type.cpp line 2419:

> 2417:   } else {
> 2418:     return make(elem, length);
> 2419:   }

For non predicated arch, do we expect this function to be called? Or at least should we assert elem->array_element_basic_type() is a boolean for the else{} block?

src/hotspot/share/opto/type.cpp line 2524:

> 2522:   if (!t->isa_vectmask()) {
> 2523:     return false;
> 2524:   }

Maybe TypeVect::eq/hash also need to have such check?

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

PR: https://git.openjdk.java.net/jdk/pull/2768