[aarch64-port-dev ] RFR: 8075930: AARCH64: Use FP Register in C2
aph at redhat.com
Wed Apr 22 09:54:26 UTC 2015
On 04/22/2015 10:40 AM, Edward Nevill wrote:
> Yes, update_map_with_saved_link does take care of R29 and I have
> stepped through it in gdb to ensure that link_addr is in fact
> pointing at the saved fp.
> I made R29 SOE rather than NS because I simply copied what was done
> on x86 where RBP is marked as SOE.
> I don't believe it makes any difference to the code generation since
> we don't support callee saved registers, therefore it won't attempt
> to save R29 on entry even if it is marked as SOE. However, it may be
> clearer to mark it as NS.
> If there is no other feedback shall I prepare a revised patch with
> R29 marked NS?
I really want to understand this properly. Are we sure that when
deoptimization happens (or when the stack is scanned for GC roots
during a safepoint) the R29 saved by our callee (which may be native
code) will be correctly processed?
As I understand it, garbage collection would have to rewrite the R29
saved by a native code prologue for this to work. But we don't even
know where in the frame native functions save FP, so I don't see how
this can possibly work.
More information about the hotspot-dev