RFR: 8338407: Support grouping several of existing regs into a new one

[Hamlin Li]

On Wed, 4 Sep 2024 09:13:11 GMT, Dean Long <dlong at openjdk.org> wrote:

> OK, I think I see the problem that approach. I believe the reason vecD on arm32 works is because there is a VecD ideal type that has the correct size. Using `match(VecA)` will give the wrong size for groups like vReg_V2_m2.

Yes.

> We would need maybe a new syntax, like `match(VecA[2])` or `match(VecA[4])`.

We could have something like `match(VecA[2])`.

In this pr, I'm implementing a similar one, it will looks like below

operand vReg_V2M2()
%{
  group(vReg_V2, vReg_V3)
%}

and

operand vReg_V8M4()
%{
  group(vReg_V8, vReg_V9, vReg_V10, vReg_V11)
%}

For a more detailed demo of its usage, please have a look at this [merged pr](https://github.com/openjdk/jdk/compare/master...Hamlin-Li:jdk:explicit-v-reg-group-v3) (merge of this pr and riscv demo usage, I say `demo` because if this pr is accepted, there're more code in riscv to be changed(i.e. simplied))

The good part of this `group operand` implementation is that it does not change anything inside chaitin reg allocation, it does not change anything for any existing `operand`. A `group operand` is just a "grouping" of other operands, a `group operand` itself does not mean anything to the underlying (or to say the underlying has no knowledge of this `group operand`, especially the chaitin), an `group operand` is just "ungrouped" when parsing the `instruct`.

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

PR Comment: https://git.openjdk.org/jdk/pull/20775#issuecomment-2329351107