makeAddress and large frame sizes

[D.Sturm]

On 29 April 2014 19:38, Tom Rodriguez <tom.rodriguez at oracle.com> wrote:

>
> C2 has a bailout when emitting the spill.
>
>     // Better yet would be some mechanism to handle variable-size matches
> correctly
>     if (!Assembler::is_simm13(offset + STACK_BIAS)) {
>       ra_->C->record_method_not_compilable("unable to handle large
> constant offsets");
>
> C2’s register allocator allocates stack slots as if they were registers so
> the frames don’t tend to be as large because there’s a lot of reuse.  In 64
> bit, I think biasing of SP also gives you greater effective reach, at least
> for the interesting part of the frame.
>
> Interestingly the aarch64.ad doesn’t seem to have equivalent code.
> http://hg.openjdk.java.net/aarch64-port/jdk8/hotspot/file/9d641fdeea4d/src/cpu/aarch64/vm/aarch64.ad
> I can’t see where it’s handled at all.
>
> That’s a pretty limited reach.  It can be hard to do a backend without at
> least one scratch register for reasons like this.  The hotspot aarch port
> has two.
>
> // r8 is used for indirect result location return
> // we use it and r9 as scratch registers
> REGISTER_DECLARATION(Register, rscratch1, r8);
> REGISTER_DECLARATION(Register, rscratch2, r9);
>
> 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.

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.