[aarch64-port-dev ] Code for frame setup is a bit ... odd?
Andrew Dinn
adinn at redhat.com
Fri Nov 22 05:35:23 PST 2013
On 22/11/13 12:28, Andrew Dinn wrote:
> On 22/11/13 11:57, Andrew Haley wrote:
>> Note that we're creating a stackframe of 16 bytes that isn't used. I wonder
>> what's going on here. x86 seems to do the same thing:
>
> There is a reason for this, documented deep in the depths of the stub
> code but I cannot recall exactly where (arch specific stubGenerator
> code???). I think it is because something needs a scratch stack area.
> I'll take a look and post when I find it.
The culprit is Compiler::Compile() -- the one which compiles a method
rather than a stub. It ensures that C->frame_slots() is always positive
because it adds an extra slot to the frame for use by deopt code:
compile.cpp:856
// Now that we know the size of all the monitors we can add a fixed slot
// for the original deopt pc.
_orig_pc_slot = fixed_slots();
int next_slot = _orig_pc_slot + (sizeof(address) /
VMRegImpl::stack_slot_size);
set_fixed_slots(next_slot);
This percolates into the definition of Matcher::compute_old_SP
(matcher.cpp) where it is rounded up from 0x8 to 0x10 and, in turn, this
gets used to compute the value of _frame_slots (compile.cpp again). So,
_frame_slots is always a minimum of 0x20 which, even after removing the
0x10 for in_preserve_slots (pushed FP and LR) always leaves a positive
frame size.
regards,
Andrew Dinn
-----------
More information about the aarch64-port-dev
mailing list