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