[aarch64-port-dev ] AArch64 register usage questions

[Andrew Haley]

On 20/03/17 21:56, White, Derek wrote:
> 
> I've been looking at the aarch64 port's register usage, and compared
> against Oracle's arm port, and have a few questions and
> observations:
> 
> Comparing the enum in c1_defs_aarch54.hpp vs. the enum in the arm
> code (and doing some constant folding by hand), you get:
> 
> 
> I don't expect these values to match, but some items stand out:
> 
> - AArch64 has fewer caller-saves registers, but more callee-saves
> registers defined above.

You have to distinguish between the Java calling convention and the C
calling convention.  Java saves everything, C only saves a subset.
There's no point saving registers that are not callee-clobbered.

> o But the Aarch64 code has comments like: // FIXME: There are no
> callee-saved.

That's right: there are none in the Java convention.  Everything
(except FP) gets clobbered on a call in the Java calling convention.

> o   And C2 does not define any SOE registers.
> 
> o   Is C1 using few registers than it could? Than it should?
>
> o   And/or is C2?

Just one: the frame pointer.  It might also be that C1 doesn't use the
compressed OOPs base, so we could use that.  We haven't done much work
optimizing C1 because it is C1: there is very little reward.

> o   There are other comments, such as above generate_call_stub(), that says:
> 
> ?  // we don't need to save r16-18 because Java does not use them

Tha's not a correct comment.  We don't need to save r16-18 because the
APCS doesn't need us to.

> ?  The comment says r16, but doesn't seem to match pd_first_callee_saved_reg.

r16 is not callee-saved, as inspection of the APCS will show.

> ?  I don't see where r18 came from.
> 
> -        pd_first_byte_reg, pd_last_byte_reg and last_byte_reg() seem unused.
> 
> Looking at the register definitions in aarch64.ad and other places:
> 
> 
> - Aarch64 always allocates r27 to use for compressed oops
> (rheapbase). Arm32/64 only allocates the register if CompressedOops
> is enabled.
>
> o In one sense the Aarch64 approach seems reasonable. I think the
> default setting for CompressedOops will be true until heap sizes get
> huge (e.g. somewhere past 256GB.), so there may not be much reason
> to optimize the non-CompressedOops path.
> 
> o If we really wanted to use r27 for compiled code, we could
> probably only allocate r27 for rheapbase if
> (Universe::narrow_oop_base() != NULL).

That's correct.  We should do that.  We should also use FP: this would
be advantageous because it's the only callee-saved register in the
Java calling convention.

Andrew.