Re: PATCH: Turn on -fomit-frame-pointer by default for 32bit Linux/x86

[Uros Bizjak <ubizjak at gmail dot com>]

On Thu, Aug 12, 2010 at 7:22 PM, Jack Howarth <howarth@bromo.med.uc.edu> wrote:

>> >>>> 2010-08-12 ?H.J. Lu ?<hongjiu.lu@intel.com>
>> >>>> ? ? ? ? ? ?Uros Bizjak ?<ubizjak@gmail.com>
>> >>>>
>> >>>> ? ? ? ?* config.gcc: Handle --enable-frame-pointer.
>> >>>>
>> >>>> ? ? ? ?* configure.ac: Add --enable-frame-pointer.
>> >>>> ? ? ? ?* configure: Regenerated.
>> >>>>
>> >>>> ? ? ? ?* config/i386/i386.c (USE_IX86_FRAME_POINTER): Default to 0.
>> >>>> ? ? ? ?(override_options): Enable -fomit-frame-pointer for 32bit code
>> >>>> ? ? ? ?if compiling for TARGET_MACHO and not optimizing for size
>> >>>> ? ? ? ?unless configured with --enable-frame-pointer. ?Enable
>> >>>> ? ? ? ?-fasynchronous-unwind-tables unless configured with
>> >>>> ? ? ? ?--enable-frame-pointer. ?Enable -maccumulate-outgoing-args
>> >>>> ? ? ? ?by default unless configured with --enable-frame-pointer.
>> >>>>
>> >>>
>> >>> Please change the ChangeLog text to something like:
>> >>>
>> >>> If not configured with --enable-frame-pointer, enable
>> >>> -fomit-frame-pointer (but not for TARGET_MACHO or when optimizing for
>> >>> size), enable -fasynchronous-unwind-tables and
>> >>> -maccumulate-outgoing-args by default.
>> >>>
>> >>
>> >> I checked it in with updated ChangeLog.
>> >>
>> >> How should we document it? We currently have
>> >>
>> >> --
>> >> @item -fomit-frame-pointer
>> >> @opindex fomit-frame-pointer
>> >> Don't keep the frame pointer in a register for functions that
>> >> don't need one. ?This avoids the instructions to save, set up and
>> >> restore frame pointers; it also makes an extra register available
>> >> in many functions. ?@strong{It also makes debugging impossible on
>> >> some machines.}
>> >>
>> >> On some machines, such as the VAX, this flag has no effect, because
>> >> the standard calling sequence automatically handles the frame pointer
>> >> and nothing is saved by pretending it doesn't exist. ?The
>> >> machine-description macro @code{FRAME_POINTER_REQUIRED} controls
>> >> whether a target machine supports this flag. ?@xref{Registers,,Register
>> >> Usage, gccint, GNU Compiler Collection (GCC) Internals}.
>> >>
>> >> Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, @option{-Os}.
>> >> --
>> >>
>> >> It was never correct for x86 and is wrong today.
>> >
>> > Perhaps something like:
>> >
>> > Index: invoke.texi
>> > ===================================================================
>> > --- invoke.texi (revision 163191)
>> > +++ invoke.texi (working copy)
>> > @@ -5993,6 +5993,11 @@
>> > ?whether a target machine supports this flag. ?@xref{Registers,,Register
>> > ?Usage, gccint, GNU Compiler Collection (GCC) Internals}.
>> >
>> > +Starting from GCC version 4.6, the default setting for 32-bit x86 targets
>> > +has been changed to @option{-fomit-frame-pointer}. New behavior can be
>> > +reverted back to @option{-fno-omit-frame-pointer} by configuring GCC with
>> > +the @option{--enable-frame-pointer} configure option.
>> > +
>> > ?Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, @option{-Os}.
>> >
>> > ?@item -foptimize-sibling-calls
>> >
>>
>> We default to --disable-frame-pointer only for 32bit x86 Linux and
>> MACHO target always has -fno-omit-frame-pointer as default.
>
> HJ,
> ?I thought that, in i386.c, we only had omit-frame-pointer disabled
> for 64-bit, no?

We don't ENABLE it for 32bit MACHO now.

BTW: If someone figures why "... for now" (and if perhaps that time
already passed), we can easily fix the condition. ATM it just mirrors
the 64bit one.

Uros.