[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-graal-dev
Subject:    Re: makeAddress and large frame sizes
From:       "D.Sturm" <D.Sturm42 () gmail ! com>
Date:       2014-04-29 18:19:53
Message-ID: CANUHqqS0fpcpdP9=s2LG44srJ9B-6GvBMFGzQWu07fR_aE6J5g () mail ! gmail ! com
[Download RAW message or body]

On 29 April 2014 20:09, Tom Rodriguez <tom.rodriguez@oracle.com> wrote:

>
>> Have you managed to not have any scratch registers?
>>
> As I understand it (at least the convention I followed) the naming there
> is purely for "documentation" - basically those registers are guaranteed to
> not be in use at the start/end of a method so we can use them as scratch
> registers
> when setting up the stack, etc. But during normal codegen those two are
> just two normal registers.
>
>
> C2 doesn't mention r8 or r9 anywhere in aarch64.ad so they are definitely
> not allocatable registers there.  Also this comment indicates that C1 does
> the same:
>
> // follow the C1 compiler in making registers
> //
> //   r0-r7,r10-r26 volatile (caller save)
> //   r27-r32 system (no save, no allocate)
> //   r8-r9 invisible to the allocator (so we can use them as scratch regs)
>
> Good to know, can't say I missed not having them available so far, the
only places where I can't ask the register allocator for a register is in
places where I can guarantee that the registers were already spilled anyhow
if used. But if HotSpot doesn't use them I'll probably run into problems
with deop, have to look at that in detail.

I guess the Aarch64 c1/2 uses scaled transfers as well - should probably
> raise the issue about the bailout in case of "offset >= 2^14" just for
> sanity though.
>
> It must be.  I think it may switch to the scaled mode based on the size of
> the operation down in Address::encode.  The encoding machinery in the aarch
> assembler is a bit hard to decode.  That's some serious magic to bury that
> deep without some asserts too.
>
> tom
>
Oh good to know that it's not just me and my inexperience with HotSpot
conventions :-)
[prev in list] [next in list] [prev in thread] [next in thread]