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

[Jatin Bhateja]

On Thu, 18 Mar 2021 11:31:32 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86_32.ad line 271:
>> 
>>> 269:     // curruption of value held in K1 register.
>>> 270:     const_cast<RegMask*>(&_OPMASK_REG_mask)->Remove(OptoReg::as_OptoReg(k1->as_VMReg()));
>>> 271:     const_cast<RegMask*>(&_OPMASK_REG_mask)->Remove(OptoReg::as_OptoReg(k1->as_VMReg()->next()));
>> 
>> Will changing your kReg operand by adding a new reg_class without k0/k1 or removing k0/k1 from opmask_reg (but keep in chunk2) be simpler?
>
> I agree with @nsjian. Removing k0/k1 from `kReg` definition would be simpler and cleaner.
> 
> `reg_mask_init` handles 2 cases:
>   * RegMask depends on runtime conditions (e.g., `-XX:+/-PreserveFramePointer`);
>   * save on repetitive definitions and derive a reg mask from another definition (`_PTR_REG_mask`, `_LONG_NO_RAX_RDX_REG_mask`). 
> 
> `kReg` doesn't fall into any of those categories.

Hi Vladimir, Ningsheng, 

Removal of K1 from allocation set is just a temporary workaround till we fix existing post-loop multi-versioning handling, mask corresponding to tail loop trip count gets stored in hard-coded K1 register, probably for consumption by predicated instructions in last post loop iteration of loop body, though I could not fully explore that part where its getting used. Removing register definitions for K0/K1 altogether would mean we will have to adjust KRegisterImpl::number_of_registers from 8 down to 6 which may not be our long term intent.

Thus reg_mask_init seemed a safe location for dynamically removing registers from opmask register class in the mean time.

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

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