RFR: JDK-8214527 AArch64: ZGC for Aarch64

[Stuart Monteith]

Yes, let's leave the renaming until JDK14 - I was aiming for the patch
to make JDK13, but we'll see.

The registers are being defined here in order for the LoadBarrier for
ZGC in z_aarch64.ad to spill them while it does the barrier
correction. I had thought the vector registers would need to have
their full 128 bits spilled, if they happened to be live - this is the
same as what is done for z_x86_64.ad .
I'm currently trying to catch the registers spilled with the current
code - not with much luck so far. The autovectorization is sensitive
enough such that that is proving difficult (as aph pointed out).

Thanks,
    Stuart

On Thu, 13 Jun 2019 at 12:17, Andrew Dinn <adinn at redhat.com> wrote:
>
> On 13/06/2019 11:13, Stuart Monteith wrote:
> > I also thought that the comment should be "64-bit" rather than
> > "128-bit", but what I did was consistent with v0_reg to v3_reg. I
> > presume one of them is wrong.
> Yes, Ningsheng is correct. The x86 equivalents for AArch64 registers V0,
> V0_H, V0_J and V0_K etc are declared with names XMM0, XMM0b, XMM0c and
> XMM0d etc. The 64 bit vector (VecD) registers are allocated as pairs
> like {XMM0, XMM0b} etc. So, the equivalent AArch64 pairs {V0, V0_H} etc
> also correspond to VecD registers. So, the original comment ought to be
> corrected to say 64 bits.
>
> Also, it was probably a misnomer to use _H/_J/_K suffices for the
> AArch64 names. I believe the _H suffix on an general purpose register
> was meant to identify the high half of a 64 bit register. The b/c/d
> suffices on xmm float registers identify successive higher 32 bit
> elements of the float register. We probably should have followed the
> same convention with AArch64 i.e. V0b, V0c V0d but it is not a big
> problem that we have not.
>
> Another thing: those 4 original register class definitions (v0_reg etc)
> are currently being used to define fixed target tmp register operands
> (vRegD_V0, etc) for specific instruct definitions (string_compare,
> string_inflate etc). It would be better if the allocator was allowed to
> pick registers rather than forcing the instructions to use these
> specific targets. Still, that is probably best left for a follow-up patch.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Senior Principal Software Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander