| Message ID | AANLkTi=FxbGb=sqr-+L0_tHwunFQS+0AqabarkEG10n7@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Thu, Aug 12, 2010 at 10:00 AM, Uros Bizjak <ubizjak@gmail.com> wrote: > On Thu, Aug 12, 2010 at 6:43 PM, H.J. Lu <hjl.tools@gmail.com> 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.
On Thu, Aug 12, 2010 at 10:03:27AM -0700, H.J. Lu wrote: > On Thu, Aug 12, 2010 at 10:00 AM, Uros Bizjak <ubizjak@gmail.com> wrote: > > On Thu, Aug 12, 2010 at 6:43 PM, H.J. Lu <hjl.tools@gmail.com> 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? /* 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; if (flag_omit_frame_pointer == 2) flag_omit_frame_pointer = 0; if (flag_asynchronous_unwind_tables == 2) flag_asynchronous_unwind_tables = 0; if (flag_pcc_struct_return == 2) flag_pcc_struct_return = DEFAULT_PCC_STRUCT_RETURN; } Jack > > > > -- > H.J.
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.
On Thu, Aug 12, 2010 at 07:26:37PM +0200, Uros Bizjak wrote: > 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. 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)? Jack > > Uros.
On 08/12/2010 10:39 AM, Jack Howarth wrote: > 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)? Jack With dwarf2 debugging there is no impairment. This is mostly a reference to stabs debugging, which does require the frame pointer. r~
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.
On 12 Aug 2010, at 18:42, Richard Henderson wrote: > On 08/12/2010 10:39 AM, Jack Howarth wrote: >> 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)? Jack > > With dwarf2 debugging there is no impairment. This is mostly a > reference to stabs debugging, which does require the frame pointer. well, we default to dwarf2 darwin >= 9 and I recommend it for darwin 8 So I'd think we can just issue an advice to use --enable-frame-pointer for darwin <= 7, for the very small number of people who would be doing this. Iain
On 08/12/2010 10:49 AM, IainS wrote: > well, we default to dwarf2 darwin >= 9 and I recommend it for darwin 8 > > So I'd think we can just issue an advice to use > --enable-frame-pointer for darwin <= 7, for the very small number of > people who would be doing this. You could just as easily tweak the default on a os-version basis in config.gcc, as with the setting for linux. r~
On Aug 12, 2010, at 10:39 AM, Jack Howarth wrote: >> We don't ENABLE it for 32bit MACHO now. > The only comment I can find in Apple's documentation on this is at... I'm fine with the configure option forcing the default for darwin, if people want to do that. The option is fine for people that know what they're doing. In fact, I'd argue that it should affect darwin equally. On darwin, we have CrashReporter that walks the stack but has yet to be enhanced to read dwarf. When combined with system libraries that create new threads for you, and the fact when something crashes, it snaps _all_ stacks from all threads, we wind up wanting async thread stack walking as well. The reports can't be very complete, if people use this option, but, normal developers can never see those reports, so the fact they are less useful, is less interesting to most people. For developers, on the machine they built software for, they will have to live with their decision, we shouldn't interfere with it. Also, Shark (performance monitoring tool suitable for developers) isn't going to be able to walk the stack, but again, that is the developers choice. The general disclaimer could be enhanced to say that CrashReporter and Shark will provide less useful data if this configure option is used, if one wanted. Though, that would be done in a wiki article as well.
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