Re: Frame pointer optimization issues

[Richard Earnshaw <rearnsha at arm dot com>]

On 21/08/14 00:24, Richard Henderson wrote:
> On 08/20/2014 08:22 AM, Wilco Dijkstra wrote:
>> 2. Change the mid-end to call <arch>_frame_pointer_required even when
>> !flag_omit_frame_pointer.
> 
> Um, it does that already.  At least as far as I can see from
> ira_setup_eliminable_regset and update_eliminables.
> 
> It turns out to be much easier to re-enable a frame pointer for a given
> function than to disable a frame pointer.  Thus I believe that you should
> approach -momit_leaf_frame_pointer as setting flag_omit_frame_pointer, and then
> re-enabling it in frame_pointer_required.  This requires more than one line in
> common/config/arch/arch.c, but it shouldn't be much more than ten.
> 
>> A second issue with frame pointers is that update_eliminables() in reload1.c might set
>> frame_pointer_needed to false without any checks.
> 
> How?  I don't see that path, since the very first thing update_eliminables does
> is call frame_pointer_required -- even before it calls can_eliminate.
> 
> Incidentally, I was working on exactly this (plus improving the unwind info)
> before I left on vacation a couple weeks ago.  Note that you'll also need to
> remove x29 from the fixed registers before eliminating the frame pointer does
> any real good.

Removing x29 from the list of fixed registers will cause any code
relying on a frame chain to crash horribly (external profiling agents,
for example); this conforms to the second option for frame-pointer use
in AAPCS64.  I've seen very little code that really benefits from an
additional register here (performance mostly comes from savings in the
prologue/epilogue), so I think users should have to explicitly remove it
from the fixed list (-fcall-saved-x29) if that's their preference.

R.