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

[Uros Bizjak]

On Thu, Aug 12, 2010 at 7:39 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.
>
> The only comment I can find in Apple's documentation on this is at...
>
> http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html
>
> The saved frame pointer (optional) contains the base address of the caller’s stack frame.
> You can use the gcc -fomit-frame-pointer option to make the compiler not save, set up, and restore the frame pointer in function calls that don’t need one, making the EBP register available for general use. However, doing so may impair debugging.
>
> So it sounds like the same issue on linux. Would the debugging impairment be any different on
> Mac OS X than on Linux (at least for the FSF gdb)?

I really don't know, but you could enable all this for Darwin by
playing in config/i386.c, around line 3270:

--cut here--
#ifndef USE_IX86_FRAME_POINTER
#define USE_IX86_FRAME_POINTER 0
#endif

  /* Set the default values for switches whose default depends on TARGET_64BIT
     in case they weren't overwritten by command line options.  */
  if (TARGET_64BIT)
    {
      if (flag_zee == 2)
        flag_zee = 1;
      /* Mach-O doesn't support omitting the frame pointer for now.  */
      if (flag_omit_frame_pointer == 2)
	flag_omit_frame_pointer = (TARGET_MACHO ? 0 : 1);
      if (flag_asynchronous_unwind_tables == 2)
	flag_asynchronous_unwind_tables = 1;
      if (flag_pcc_struct_return == 2)
	flag_pcc_struct_return = 0;
    }
  else
    {
      if (flag_zee == 2)
        flag_zee = 0;
      /* Mach-O doesn't support omitting the frame pointer for now.  */
      if (flag_omit_frame_pointer == 2)
	flag_omit_frame_pointer =
	  (TARGET_MACHO ? 0 : !(USE_IX86_FRAME_POINTER || optimize_size));
      if (flag_asynchronous_unwind_tables == 2)
	flag_asynchronous_unwind_tables = !USE_IX86_FRAME_POINTER;
      if (flag_pcc_struct_return == 2)
	flag_pcc_struct_return = DEFAULT_PCC_STRUCT_RETURN;
    }
--cut here--

Just put both "flag_omit_frame_pointer=" and
"flag_asynchronous_unwind_tables=" to "1" and you are done.

Uros.