RFR: 8233948: AArch64: Incorrect mapping between OptoReg and VMReg for high 64 bits of Vector Register

[Joshua Zhu (Arm Technology China)]

Hi,

Please review the following patch:
JBS: https://bugs.openjdk.java.net/browse/JDK-8233948
Webrev: http://cr.openjdk.java.net/~jzhu/8233948/webrev.00/

In register definition of aarch64.ad, each vector register is defined as 4 slots with its calling convention, ideal type, ... and its VMReg value. These VMReg values in reg_def are used by ADLC to generate mapping between OptoReg and VMReg: opto2vm[].

But VMReg is treated as 2 slots inconsistently for vector register [1]. This causes incorrect mapping between VMReg and OptoReg for high 64 bits of vector register.

If we write the following codes which will access high 64 bits of vector register in a way like vector_calling_convention in panama branch [2]:
    VMReg vmreg = v0->as_VMReg();
    VMRegPair p;
    p.set_pair(vmreg->next(3), vmreg);
And convert the VMRegPair into OptoReg [3]:
    Regmask rm;
    OptoReg::Name reg_fst = OptoReg::as_OptoReg(p.first());
    OptoReg::Name reg_snd = OptoReg::as_OptoReg(p.second());
    tty->print("fst=%d snd=%d\n", reg_fst, reg_snd);
    for (OptoReg::Name r = reg_fst; r <= reg_snd; r++) {
      rm->Insert(r);
    }
In this case, for V0's VMRegPair, first VMReg's value is 64 and second one is 67. After conversion by as_OptoReg(), first OptoReg becomes 124 and second one becomes 129. Then totally 6 bits of RegMask are set incorrectly, should be 4 bits (represent 4 slots/halves).

VMReg, opto2vm[] and vm2opto[] are dumped by [4] as below for reference:
    http://cr.openjdk.java.net/~jzhu/8233948/RegDump_before_change.log

opto2vm[] has the following items:
    OptoReg: 126, VMReg: 66
    OptoReg: 127, VMReg: 67
    OptoReg: 128, VMReg: 66
    OptoReg: 129, VMReg: 67
OptoReg pair [126, 127] and [128, 129] are both mapped to the same VMReg Pair [66, 67].
vm2opto are then generated by traverse of opto2vm [5].
    VMReg: 66, OptoReg: 128
    VMReg: 67, OptoReg: 129
This caused incorrect RegMask generated in above case.

However for floating-point register, bottom 64 bits of NEON vector register overlaps with floating-point register. Their VMReg and corresponding mapping is still consistent, therefore this issue is not exposed. But I think we should still fix it to make the codes clean and avoid potential issue in future.

After fix, the dump is:
    http://cr.openjdk.java.net/~jzhu/8233948/RegDump_after_change.log

[1] https://hg.openjdk.java.net/jdk/jdk/file/d595f1faace2/src/hotspot/cpu/aarch64/vmreg_aarch64.inline.hpp#l35
[2] https://hg.openjdk.java.net/panama/dev/file/43bc39c09590/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#l1140
[3] https://hg.openjdk.java.net/panama/dev/file/43bc39c09590/src/hotspot/share/opto/matcher.cpp#l1360
[4] http://cr.openjdk.java.net/~jzhu/8233948/dump.patch
[5] https://hg.openjdk.java.net/jdk/jdk/file/d595f1faace2/src/hotspot/share/opto/c2compiler.cpp#l59

Best Regards,
Joshua