[aarch64-port-dev ] How to skip the synchronization entry
Andrew Dinn
adinn at redhat.com
Wed Aug 15 08:13:33 UTC 2018
On 15/08/18 08:05, Patrick Zhang wrote:
> I have a very simple function that directly returns the an input int
> parameter inside, there are x29, x30 registers being protected
> before/after "mov w0 w2". I have two questions here:
> 1. Are these Link Register and Frame Pointer respectively according
> to the A64 instruction set document?
Yes. This is part of a standard method prologue/epilogue to set up and
clear a stack frame for a method call. Normally, in the prologue you
will also see stack banging code i.e. writes further up the stack (lower
addresses) to ensure that the call does not run off the end of the
stack. In this case it may have been omitted because the function does
not require any save slots on the stack.
> 2. Any special flags to remove them for debugging purpose? I tried
> -XX:-PreserveFramePoint but no effect.
I think you mean -XX:-PreserveFramePointer. That flag does not stop the
current frame pointer being stored on the stack. All it does is stop the
frame pointer register being updated to point to the the newly stored
location for rfp. If you want to see how this code is generated look at
method MacroAssembler::build_frame in macroAssembler_aarch64.cpp.
There is no benefit to saving/restoring lr and not also saving/restoring
rfp. For any stack push have to increment the stack by a multiple of 2.
So, if you do push lr then you also might as well push rfp.
Of course, for very small function calls when you know you won't need
any stack slots you could avoid saving both rfp and lr. However, that is
not worth bothering with as a special-case optimization because for a
small function that gets called a lot you can be very sure the JIT
compiler will inline the call.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
More information about the aarch64-port-dev
mailing list