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

[Vladimir Ivanov]

>> Matcher::perdicate_reg_type() is not enough to hide the 
>> platform-specific choice. The choice of TypeLong introduces 
>> significant complexity in shared code (e.g, PhiNode and 
>> MachSpillCopyNode-related changes). Moreover, SVE will have to choose 
>> an alternative and more generic representation. Hence, it makes the 
>> ad-hoc changes needed for RegVMask+TypeLong even less attractive.
>>
>> Considering there's active work going on on SVE support, I'm in favor 
>> of collaborating on unified representation between platforms and rely 
>> on it in the first version.
> 
> I agree.  Would it help to have TypeMask as a #define of TypeLong,
> in the first versions?  (I’m thinking of TypeX as a similar pseudo-type.)

Unfortunately, I don't see how a macro could help here. It would still 
be an instance of TypeLong and the code would have to explicitly 
dispatch between mask and non-mask cases when choosing appropriate ideal 
register.

I find TypeVMask which is proposed as part of SVE support (Ningsheng 
mentioned it earlier) a much better alternative:
 
https://github.com/openjdk/panama-vector/pull/40/commits/3f69d40f08868062e2cc144b3b757dcbaa2db2d1

Also, a comment on process: Ningsheng and Xiaohong started with RFC on 
panama-dev which looks more convenient. It allows to commit earlier and 
iterate quicker compared to jdk. It makes sense to come up with missing 
primitives first which satisfy both AVX-512 and SVE requirements. Once 
they are available, proper support can follow. And alternative 
implementations can happily coexist in Panama repo while the 
implementations converge.

Best regards,
Vladimir Ivanov