Re: [PATCH] PR 16373: -fomit-frame-pointer when optimizing on x86

[Roger Sayle <roger at eyesopen dot com>]

On Mon, 12 Jul 2004, Richard Henderson wrote:
> On Mon, Jul 12, 2004 at 01:24:14AM -0400, Jakub Jelinek wrote:
> > I don't think we can turn -fomit-frame-pointer by default on unless
> > we also -fasynchronous-unwind-tables, because otherwise things like
> > glibc's backtrace(3) has zero chance of ever working.
>
> Indeed.  We might talk about turning on -momit-leaf-frame-pointer
> again, though.

Reading glibc's implementation on backtrace for i386, I think I have
a cunning plan.  The code in sysdeps/i386/bactrace.c assumes that
the full backtrace can be recovered by traversing a linked list of
frames, starting with the current frame %ebp.

A compromise which provides most of the performance advantages of
-fomit-frame-pointer but still allows backtrace(3) to function might
be for the i386 to treat %ebp as a pseudo-fixed register.  The theory
is that over all subroutine calls %ebp must contain a valid stack
frame pointer, but not necessarily for the current function.  Any
function that uses a frame-pointer behaves as it always has.  Any
function, that doesn't must preserve the %ebp from its parent when
calling children.  This ensures that backtrace still sees a linked
list of stack frames, just not *every* stack frame.  To a user of
backtrace, this is no different than inlining.  In the worst case,
backtrace will see a valid backtrace containing just "main" and its
parents.

Theoretically, GCC could still use %ebp in leaf functions, or in
non-leaf functions provided that it restore its value prior to
making any function calls.

This scheme allows backtrace(3) to continue to function even when
mixing and interleaving functions compiled with and without
-fomit-frame-pointer.   Almost all of the dramatic performance
improvement with -fomit-frame-pointer is from not setting up and
restoring a stack-frame, the loss of %ebp as an additional cheap
register in this scheme should be negligible.


For exception handling code, this should even be a performance
win, as backtrace can skip "uninteresting" stack frames without
a frame-pointer, assuming that all functions (or children of
functions) that catch exceptions are compiled with a frame pointer.


Hopefully, this makes some kind of sense, and is a generalization
of -momit-leaf-frame-pointer.  If you're unhappy with this approach,
I'm also investigating "plan B", but that requires significantly
more code.


Is this doable?


Roger
--