[PATCH] Omit frame pointer and fix %ebp by default on x86 (take 3)

Roger Sayle roger@eyesopen.com
Mon Aug 16 18:52:00 GMT 2004

On Mon, 16 Aug 2004, Richard Henderson wrote:
> On Sun, Aug 15, 2004 at 06:59:51PM -0600, Roger Sayle wrote:
> > 	* config/i386/i386.c (override_options): Default 32-bit targets to
> > 	"-fomit-frame-pointer -ffixed-ebp" when optimizing if the user
> > 	hasn't explicitly specified a frame pointer command line option.
> Excuse me for waffling, but I wonder if this buys us anything
> at all?  If backtrace(3) always returns __libc_start_main, and
> nothing else, have we done the user any favours?

The primary motivation is to reduce code size and increase performance
for the 99.99% of applications that don't use backtrace.  Unlike
Intel's icc compilers, GCC suffers a severe performance hit for
rigorously maintaing a stack frame.  This "concession" allows code
to be compiled for performance without causing backtrace to segfault.

Think of it exactly like single-use function inlining.  Both this patch
and function inlining have two major benefits; they make compiled code
faster and smaller(!).  In both cases, use of these optimization
techniques interferes with backtrace(3), but neither fatally.
Users who wish a full backtrace need to use both -fno-inline-functions
and -fno-omit-frame-pointer (or compile without optimizations) to see
every stack frame listed.

Additionally, it allows us to safely mix code compiled with stack
frames with code compiled without.  For example, heavily recursive
functions like "qsort" can be compiled without frame pointers
knowing that they themselves neither throw nor catch exceptions,
but allowing the user specified callback to propagate exceptions
back to any frames above qsort.

Clearly there are code size and performance advanatages of this
patch (one of the largest in recent years).  Are you arguing that
we should just make full "-fomit-frame-pointer" the default and
just require backtrace users (and the libraries they rely on) to
use the appropriate command line options?


More information about the Gcc-patches mailing list