[aarch64-port-dev ] RFR: JDK-8214527 AArch64: ZGC for Aarch64

[Stuart Monteith]

Yes, my concern was only 64-bits of v8-v17 are callee saved in the ARM
aapcs, so essentially all vector registers are caller saved.

I've updated the patch to incorporate Ningsheng's suggestion to just
match the clobbered registers practice of saving r0-r18:

https://cr.openjdk.java.net/~smonteith/8214527/webrev.6/

Thanks,
    Stuart

On Thu, 13 Jun 2019 at 13:59, Andrew Haley <aph at redhat.com> wrote:
>
> On 6/13/19 1:56 PM, Andrew Dinn wrote:
> > On 13/06/2019 13:24, Stuart Monteith wrote:
> >> 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 .
> >
> > Well, as far as I understand it: if the registers happened to be live
> > with 128 bit data loaded by C2 generated code then they should get
> > spilled as 128 bits values when an instruction is generated that KILLs
> > the bottom 64 bits.
> >
> > Of course, there is also the question of what C2 ought to do to preserve
> > incoming values in callee-save float registers. I am not sure of this
> > but I thought callers could only expect 64 bit float register data to be
> > saved by the callee. Is that right? Or did I make that last bit up?
>
> There are no callee-save float registers in the Java calling convention.
> Phew. ;-)
>
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671