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

[Vladimir Ivanov]

On Thu, 18 Mar 2021 11:03:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/type.hpp line 1714:
>> 
>>> 1712: 
>>> 1713: inline const TypeVect *Type::isa_vect() const {
>>> 1714:   return (_base >= VectorM && _base <= VectorZ) ? (TypeVect*)this : NULL;
>> 
>> I'm sorry that I still cannot understand why `"TypeVectMask"` is needed to extend from `"TypeVect"`. Is there any other important reasons besides of the logic extension? I'm worried if there is any influence that these two methods treat the `VectorM` as a vector? There are too much usages of these two methods that are specific for vectors especially during register allocation. I'm wondering whether there are any other usages also need the same handles like what you have fixed line 1059 in `x86_32.ad`. Did you have checked all the usages? Thanks!
>
> New mask type is indeed a vector of BYTE/BOOLEAN values, thus its ok if it goes though regular flows which processes vector type.

> There are too much usages of these two methods that are specific for vectors especially during register allocation.

I don't see any usages of `Type::isa_vect()` except in 2 asserts. RA relies on`RegMask::is_vector()` to detect vectors and it doesn't include `VectorM`.

Regarding the relation between `TypeVect` and `TypeVectMask` I don't have a strong opinion. 
There's definitely enough in common between them to have a common vector-specific supertype, but it's also desirable to avoid confusion between `is_vect()` vs `is_vectmask()`. Considering existing masks are represented as vectors, I think it's fine to leave it as is for now and revisit later when more data is available to make an informed decision.

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

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