RFR: 8262355: Support for AVX-512 opmask register allocation. [v17]
Vladimir Kozlov
kvn at openjdk.java.net
Mon Mar 29 23:05:48 UTC 2021
On Mon, 29 Mar 2021 09:05:08 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) Creation of a new concrete type TypeVectMask for mask generation nodes and a convivence routine Type::makemask which creates a regular vector types (TypeVect[SDXYZ]) for non-AVX-512 targets and TypeVectMask for a AVX-512 targets.
>>
>>
>> [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: Updating copywriter for edited files.
Few notes.
1. In `sharedRuntime_*.cpp` you have name `opmask_state_*` and `.ad` files also `opmask` and `opmask_reg_k*'. But in C2 code you call them `vectmask` which is confusing. I prefer to use the same name everywhere - `vectmask`:
const RegMask* Matcher::predicate_reg_mask(void) {
return &_OPMASK_REG_mask;
}
const TypeVect* Matcher::predicate_reg_type(const Type* elemTy, int length) {
return new TypeVectMask(TypeInt::BOOL, length);
}
2. I assume that they are used only for vectors in compiled code and in other cases the don't need to be saved/restored at safepoints.
3. In C2 shared code names are mess too: `VectorM, VMASK, RegVMask, TypeVectMask, VectorMaskCmp`. I suggest to use `VectorMask, VECTMASK, RegVectMask`.
src/hotspot/cpu/x86/register_x86.hpp line 221:
> 219: enum {
> 220: number_of_registers = 8,
> 221: max_slots_per_register = 2
Add comment. So the max size is 64 bytes?
-------------
PR: https://git.openjdk.java.net/jdk/pull/2768
More information about the hotspot-compiler-dev
mailing list