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

Jatin Bhateja jbhateja at openjdk.java.net
Thu Mar 11 11:24:08 UTC 2021


On Thu, 11 Mar 2021 08:24:08 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> But I think there should not be any mask type for those non-mask hardware targets. If in future we would like to have some type based optimization, e.g. all-true/all-false, that may be confusing with vector type.
>
>> But I think there should not be any mask type for those non-mask hardware targets.
> 
> It seems what you are calling "non-mask hardware targets" are ISAs without dedicated predicate registers. Still, it doesn't mean such ISA doesn't support masked operations (e.g., AVX/AVX2 on x86). It will be unfortunate if we have to distinguish between different mask representations in Ideal IR. `TypeVectMask` describes an "ideal" vector mask and IMO it is natural to represent it as a vector. 
> 
>>  If in future we would like to have some type based optimization, e.g. all-true/all-false, that may be confusing with vector type.
> 
> The missing piece to make it work is vector constant support. Once it's there, it'll be possible to inspect elements of a vector constant. It is not limited to masks, but nicely generalizes to all vector shapes.

Hi Vladimir, Ningsheng,

In the recent version of the patch I have demonstrated the special handling for opmask registers during de-optimization.
This code may not be relevant for base version of patch though, since only mask generating node defining an opmask register
currently is VectorMaskGenNode. 

In PhaseVector::scalarize_vbox_node we stitch the vector payload to SafePoint node by creating
a SafepointScalarObjectNode, passing the vector payload of masked class though a VectorStoreMaskNode before creating a 
SafePointScalarObjectNode will make value re-materialization process during de-optimization agnostic to existence
of predicate vectors. Wanted to know your thoughts on it?

This may further help in removing the logic to a add mask vectors to callee saved list of RegisterMap 
(accessed during object de-opt for object reallocation) since payload will always be present in a byte vector. 
It may come at an extra cost though, since register pressure over vectors may increase.

Do you suggest removing re-construction logic and addition of opmask vectors to callee save list from base patch?

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

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


More information about the hotspot-compiler-dev mailing list