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.
