This is the mail archive of the
mailing list for the GCC project.
Turn on -fomit-frame-pointer by default for 32bit Linux/x86
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: GCC Development <gcc at gcc dot gnu dot org>
- Cc: Richard Guenther <rguenther at suse dot de>, Jakub Jelinek <jakub at redhat dot com>, Mark Mitchell <mark at codesourcery dot com>, Richard Henderson <rth at redhat dot com>, jh at suse dot cz, "H.J. Lu" <hjl dot tools at gmail dot com>, Andi Kleen <andi at firstfloor dot org>, Andrew Haley <aph at redhat dot com>, David Daney <ddaney at caviumnetworks dot com>, Xinliang David Li <davidxl at google dot com>, Chris Lattner <clattner at apple dot com>
- Date: Sun, 8 Aug 2010 16:56:49 +0200
- Subject: Turn on -fomit-frame-pointer by default for 32bit Linux/x86
After recent discussions, I would like to propose a transition to
-fomit-frame-pointer for x86_32.
The transition should be smooth as much as possible, should have
option to revert to old behaviour and still providing path for the
improvement. And we have learned something from cld issues, too
I support the idea to change x86_32 defaults w.r.t. frame pointer (and
unwind tables) to the same defaults as x86_64 has.
The patch should also introduce --enable-frame-pointer configure
option (off by default) that would revert back to old x86_32
behaviour. So, if there are codes that depend on FP, their users (or
distributions) should either (re-)configure the compiler with
--enable-frame-pointer or they should use older compiler - 4.5.x will
still be supported for many years. OTOH, it looks that users don't
care that much whether backtraces on x86_64 are totally accurate, so
IMO the sky won't fall down if x86_32 misses some backtraces in the
same way. And as I have learned from the discussion, the problem is
fixable with some effort on the user's side, thus fixing both targets
in one shot.
Of course, this change and the option to revert to the previous
behaviour should be announced and documented in GCC release notes for
IMO, we have to bite the bullet from time to time in order to improve
the generated code. We should not claim that gcc is
"no-code-left-behind compiler" - from my experience, introducing new
compiler always means that some parts of the code have to be fixed (as
in case of the change to -fno-strict-aliasing).