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

Vladimir Ivanov vlivanov at openjdk.java.net
Thu Mar 18 11:57:53 UTC 2021


On Wed, 17 Mar 2021 13:10:05 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> It is just a coincidence. Considering there's a way to produce an arbitrary number of predicates using `VectorMask`, I'd prefer to see a more robust solution that won't cause us problems in the future.
>> Please, exclude `k1` from `kReg` then.
>
> For the time being I have removed K1 from allocable set, till we fix post-loop multi-versioning.

Looks good. Please, put comments before `setMask`, `jmpLoopEnd_and_restoreMask`, and `jmpLoopEndU_and_restoreMask` describing why it is safe to use `k1` there.

>> But then RA has to allocate a k-register irrespective of whether AVX512 is supported or not, doesn't it?
>
> Yes, allocation will still happen but it will not seep into any JITed instruction. Reg_Defs/Operands/RegMask/RegClass are not guarded by target checks.

Ok, now I understand how it is intended to work. Thanks for the clarifications.

I'm not fully satisfied with how it works. I'm in favor of avoiding using any functionality which is not supported by hardware. (And that's currently the case.) But considering there's no simple way to fix it right now, I'm fine with addressing it separately as a follow-up fix. 

For now, please, put extensive comments in relevant places describing why `kReg` is used unconditionally. As the code shaped now, it's confusing at the very least.

In the longer term, IMO the proper way to implement that is for ADLC to support conditional operands which depend on runtime conditions and are matched to `*noreg`s when the condition is false.

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

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


More information about the hotspot-compiler-dev mailing list