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

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

[H.J. Lu]

[-- Attachment #1: Type: text/plain, Size: 2884 bytes --]

On Wed, Jul 14, 2010 at 2:55 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Jul 14, 2010 at 6:46 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Wed, Jul 14, 2010 at 1:09 AM, Richard Guenther
>> <richard.guenther@gmail.com> wrote:
>>> On Tue, Jul 13, 2010 at 11:44 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Tue, Jul 13, 2010 at 2:02 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>>>>> On Tue, Jul 13, 2010 at 2:01 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>>>>>> On Tue, Jul 13, 2010 at 1:59 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>> What will stop working when -fomit-frame-pointer is on?
>>>>>>
>>>>>> backtraces when debugging information is not turned on.
>>>>>
>>>>> See http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01033.html and many
>>>>> more.  This is not the first time this has been discussed.
>>>>
>>>> Most of 32bit x86 assembly codes in glibc have .eh_frame section.
>>>> If backtrace is absolutely needed, they can add -fasynchronous-unwind-tables
>>>> or -fno-omit-frame-pointer.
>>>
>>> We build opensuse with -fomit-frame-pointer -fasynchronous-unwind-tables.
>>> If you want to make -fomit-frame-pointer the default then you should enable
>>> unwind tables by default.
>>>
>>
>> I will try and make it target/OS dependent.
>>
>
> Here is a patch. How does it look?
>

Here are the updated patch and spread sheet for SPEC CPU 2000/2006 on
Intel Core i7 which shows that -fomit-frame-pointer -fasynchronous-unwind-tables
improves performance by up to 12% at -O2 and 8% at -O3. For -Os, it improves
performance by up to 20%, but also increases code by up to 36%.

This patch turns on -fomit-frame-pointer -fasynchronous-unwind-tables only if
-Os isn't used.

Tested on Linux/ia32 and Linux/x86-64 with -m32. OK for trunk?

Thanks.

-- 
H.J.
---
gcc/

2010-07-25  H.J. Lu  <hongjiu.lu@intel.com>

	* config/i386/i386.c (override_options): For 32bit, default
	flag_omit_frame_pointer and flag_asynchronous_unwind_tables
	to TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT and
	TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT.

	* config/i386/i386.h (TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT):
	New.
	(TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT): Likewise.
	* config/i386/linux.h (TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT):
	Likewise.
	(TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT): Likewise.
	* config/i386/linux64.h (TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT):
	Likewise.
	(TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT): Likewise.

gcc/testsuite/

2010-07-25  H.J. Lu  <hongjiu.lu@intel.com>

	* gcc.target/i386/frame-pointer-1.c: New.
	* gcc.target/i386/frame-pointer-2.c: Likewise.
	* gcc.target/i386/frame-pointer-3.c: Likewise.
	* gcc.target/i386/frame-pointer-4.c: Likewise.
	* gcc.target/i386/frame-pointer-5.c: Likewise.

[-- Attachment #2: gcc-i386-fp-3.patch --]
[-- Type: text/plain, Size: 6781 bytes --]

gcc/

2010-07-25  H.J. Lu  <hongjiu.lu@intel.com>

	* config/i386/i386.c (override_options): For 32bit, default
	flag_omit_frame_pointer and flag_asynchronous_unwind_tables
	to TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT and
	TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT.

	* config/i386/i386.h (TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT):
	New.
	(TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT): Likewise.
	* config/i386/linux.h (TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT):
	Likewise.
	(TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT): Likewise.
	* config/i386/linux64.h (TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT):
	Likewise.
	(TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT): Likewise.

gcc/testsuite/

2010-07-25  H.J. Lu  <hongjiu.lu@intel.com>

	* gcc.target/i386/frame-pointer-1.c: New.
	* gcc.target/i386/frame-pointer-2.c: Likewise.
	* gcc.target/i386/frame-pointer-3.c: Likewise.
	* gcc.target/i386/frame-pointer-4.c: Likewise.
	* gcc.target/i386/frame-pointer-5.c: Likewise.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index dbb8949..640243e 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2985,10 +2985,27 @@ override_options (bool main_args_p)
     {
       if (flag_zee == 2)
         flag_zee = 0;
+      /* Unwind info is not correct around the CFG unless either a
+	 frame pointer is present or -maccumulate-outgoing-args is
+	 set. When both -fasynchronous-unwind-tables and
+	 -fomit-frame-pointer are turned on by default, turn off
+	 both if -mno-accumulate-outgoing-args is used.  When
+	 optimizing for size, don't turn on -fomit-frame-pointer nor
+	 -fasynchronous-unwind-tables by default.  */
       if (flag_omit_frame_pointer == 2)
-	flag_omit_frame_pointer = 0;
+	flag_omit_frame_pointer
+	  = (!optimize_size
+	     && TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT
+	     && (!TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT
+		 || !(target_flags_explicit
+		      & MASK_ACCUMULATE_OUTGOING_ARGS)));
       if (flag_asynchronous_unwind_tables == 2)
-	flag_asynchronous_unwind_tables = 0;
+	flag_asynchronous_unwind_tables
+	  = (!optimize_size
+	     && TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT
+	     && (!TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT
+		 || !(target_flags_explicit
+		      & MASK_ACCUMULATE_OUTGOING_ARGS)));
       if (flag_pcc_struct_return == 2)
 	flag_pcc_struct_return = DEFAULT_PCC_STRUCT_RETURN;
     }
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index e153920..2bb6d3e 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -467,6 +467,8 @@ extern tree x86_mfence;
 /* Extra bits to force on w/ 32-bit mode.  */
 #define TARGET_SUBTARGET32_DEFAULT 0
 #define TARGET_SUBTARGET32_ISA_DEFAULT 0
+#define TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT 0
+#define TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT 0
 
 /* Extra bits to force on w/ 64-bit mode.  */
 #define TARGET_SUBTARGET64_DEFAULT 0
diff --git a/gcc/config/i386/linux.h b/gcc/config/i386/linux.h
index 81dfd1e..61d53b5 100644
--- a/gcc/config/i386/linux.h
+++ b/gcc/config/i386/linux.h
@@ -219,3 +219,10 @@ along with GCC; see the file COPYING3.  If not see
 /* i386 glibc provides __stack_chk_guard in %gs:0x14.  */
 #define TARGET_THREAD_SSP_OFFSET	0x14
 #endif
+
+/* Turn on -fomit-frame-pointer and -fasynchronous-unwind-tables by
+   default.  */
+#undef TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT
+#define TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT 1
+#undef TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT
+#define TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT 1
diff --git a/gcc/config/i386/linux64.h b/gcc/config/i386/linux64.h
index 33b4dc9..5a02205 100644
--- a/gcc/config/i386/linux64.h
+++ b/gcc/config/i386/linux64.h
@@ -123,3 +123,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
    x86_64 glibc provides it in %fs:0x28.  */
 #define TARGET_THREAD_SSP_OFFSET	(TARGET_64BIT ? 0x28 : 0x14)
 #endif
+
+/* Turn on -fomit-frame-pointer and -fasynchronous-unwind-tables by
+   default.  */
+#undef TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT
+#define TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT 1
+#undef TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT
+#define TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT 1
diff --git a/gcc/testsuite/gcc.target/i386/frame-pointer-1.c b/gcc/testsuite/gcc.target/i386/frame-pointer-1.c
new file mode 100644
index 0000000..ed4bff6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/frame-pointer-1.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mtune=i686" } */
+/* { dg-require-effective-target ilp32 } */
+
+void bar (int);
+
+void
+foo (void)
+{
+  bar (1);
+}
+
+/* { dg-final { scan-assembler-not "pushl\[\\t \]*%ebp" } } */
diff --git a/gcc/testsuite/gcc.target/i386/frame-pointer-2.c b/gcc/testsuite/gcc.target/i386/frame-pointer-2.c
new file mode 100644
index 0000000..b951ff4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/frame-pointer-2.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mtune=i686 -mno-accumulate-outgoing-args" } */
+/* { dg-require-effective-target ilp32 } */
+
+void bar (int);
+
+void
+foo (void)
+{
+  bar (1);
+}
+
+/* { dg-final { scan-assembler "pushl\[\\t \]*%ebp" } } */
diff --git a/gcc/testsuite/gcc.target/i386/frame-pointer-3.c b/gcc/testsuite/gcc.target/i386/frame-pointer-3.c
new file mode 100644
index 0000000..7a1d4d1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/frame-pointer-3.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mtune=i686 -mpush-args" } */
+/* { dg-require-effective-target ilp32 } */
+
+void bar (int);
+
+void
+foo (void)
+{
+  bar (1);
+}
+
+/* { dg-final { scan-assembler-not "pushl\[\\t \]*%ebp" } } */
diff --git a/gcc/testsuite/gcc.target/i386/frame-pointer-4.c b/gcc/testsuite/gcc.target/i386/frame-pointer-4.c
new file mode 100644
index 0000000..330a9ce
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/frame-pointer-4.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mtune=i686 -mpush-args -mno-accumulate-outgoing-args" } */
+/* { dg-require-effective-target ilp32 } */
+
+void bar (int);
+
+void
+foo (void)
+{
+  bar (1);
+}
+
+/* { dg-final { scan-assembler "pushl\[\\t \]*%ebp" } } */
diff --git a/gcc/testsuite/gcc.target/i386/frame-pointer-5.c b/gcc/testsuite/gcc.target/i386/frame-pointer-5.c
new file mode 100644
index 0000000..11240a2
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/frame-pointer-5.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-Os -mtune=i686" } */
+/* { dg-require-effective-target ilp32 } */
+
+void bar (int);
+
+void
+foo (void)
+{
+  bar (1);
+}
+
+/* { dg-final { scan-assembler "pushl\[\\t \]*%ebp" } } */

[-- Attachment #3: gcc frame pointer.xlsx --]
[-- Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, Size: 53995 bytes --]

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

[H.J. Lu]

On Mon, Jul 26, 2010 at 9:33 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Jul 14, 2010 at 2:55 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Wed, Jul 14, 2010 at 6:46 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>> On Wed, Jul 14, 2010 at 1:09 AM, Richard Guenther
>>> <richard.guenther@gmail.com> wrote:
>>>> On Tue, Jul 13, 2010 at 11:44 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Tue, Jul 13, 2010 at 2:02 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>>>>>> On Tue, Jul 13, 2010 at 2:01 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>>>>>>> On Tue, Jul 13, 2010 at 1:59 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>>>>> What will stop working when -fomit-frame-pointer is on?
>>>>>>>
>>>>>>> backtraces when debugging information is not turned on.
>>>>>>
>>>>>> See http://gcc.gnu.org/ml/gcc-patches/2004-08/msg01033.html and many
>>>>>> more.  This is not the first time this has been discussed.
>>>>>
>>>>> Most of 32bit x86 assembly codes in glibc have .eh_frame section.
>>>>> If backtrace is absolutely needed, they can add -fasynchronous-unwind-tables
>>>>> or -fno-omit-frame-pointer.
>>>>
>>>> We build opensuse with -fomit-frame-pointer -fasynchronous-unwind-tables.
>>>> If you want to make -fomit-frame-pointer the default then you should enable
>>>> unwind tables by default.
>>>>
>>>
>>> I will try and make it target/OS dependent.
>>>
>>
>> Here is a patch. How does it look?
>>
>
> Here are the updated patch and spread sheet for SPEC CPU 2000/2006 on
> Intel Core i7 which shows that -fomit-frame-pointer -fasynchronous-unwind-tables
> improves performance by up to 12% at -O2 and 8% at -O3. For -Os, it improves
> performance by up to 20%, but also increases code by up to 36%.
>
> This patch turns on -fomit-frame-pointer -fasynchronous-unwind-tables only if
> -Os isn't used.
>
> Tested on Linux/ia32 and Linux/x86-64 with -m32. OK for trunk?

Any comments on this patch.  Any objections?

Thanks.


H.J.
---
> Thanks.
>
> --
> H.J.
> ---
> gcc/
>
> 2010-07-25  H.J. Lu  <hongjiu.lu@intel.com>
>
>        * config/i386/i386.c (override_options): For 32bit, default
>        flag_omit_frame_pointer and flag_asynchronous_unwind_tables
>        to TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT and
>        TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT.
>
>        * config/i386/i386.h (TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT):
>        New.
>        (TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT): Likewise.
>        * config/i386/linux.h (TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT):
>        Likewise.
>        (TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT): Likewise.
>        * config/i386/linux64.h (TARGET_SUBTARGET32_OMIT_FRAME_POINTER_DEFAULT):
>        Likewise.
>        (TARGET_SUBTARGET32_ASYNCHRONOUS_UNWIND_TABLES_DEFAULT): Likewise.
>
> gcc/testsuite/
>
> 2010-07-25  H.J. Lu  <hongjiu.lu@intel.com>
>
>        * gcc.target/i386/frame-pointer-1.c: New.
>        * gcc.target/i386/frame-pointer-2.c: Likewise.
>        * gcc.target/i386/frame-pointer-3.c: Likewise.
>        * gcc.target/i386/frame-pointer-4.c: Likewise.
>        * gcc.target/i386/frame-pointer-5.c: Likewise.
>

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

[Uros Bizjak]

On Mon, Aug 2, 2010 at 7:54 PM, H.J. Lu <hjl.tools@gmail.com> wrote:

>> Here are the updated patch and spread sheet for SPEC CPU 2000/2006 on
>> Intel Core i7 which shows that -fomit-frame-pointer -fasynchronous-unwind-tables
>> improves performance by up to 12% at -O2 and 8% at -O3. For -Os, it improves
>> performance by up to 20%, but also increases code by up to 36%.
>>
>> This patch turns on -fomit-frame-pointer -fasynchronous-unwind-tables only if
>> -Os isn't used.
>>
>> Tested on Linux/ia32 and Linux/x86-64 with -m32. OK for trunk?
>
> Any comments on this patch.  Any objections?

IMO, this should be approved by Release Managers, since this decision
affects distributions and their users.

I have no _technical_ objections to this patch, but I won't approve it
either due to the reason above.

Thanks,
Uros.

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

[Andrew Haley]

On 08/03/2010 10:18 AM, Uros Bizjak wrote:
> On Mon, Aug 2, 2010 at 7:54 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 
>>> Here are the updated patch and spread sheet for SPEC CPU 2000/2006 on
>>> Intel Core i7 which shows that -fomit-frame-pointer -fasynchronous-unwind-tables
>>> improves performance by up to 12% at -O2 and 8% at -O3. For -Os, it improves
>>> performance by up to 20%, but also increases code by up to 36%.
>>>
>>> This patch turns on -fomit-frame-pointer -fasynchronous-unwind-tables only if
>>> -Os isn't used.
>>>
>>> Tested on Linux/ia32 and Linux/x86-64 with -m32. OK for trunk?
>>
>> Any comments on this patch.  Any objections?
> 
> IMO, this should be approved by Release Managers, since this decision
> affects distributions and their users.
> 
> I have no _technical_ objections to this patch, but I won't approve it
> either due to the reason above.

It's hard for us to know all the use cases that this patch will break:
there may be many users who unwind the stack by following the call
chain, a technique that has worked for many years.  (And was even
sanctioned by the ABI, wasn't it?)  We'll know when if push this patch
out and hear the screams.

Is this really the right thing to do at this stage in the lifetime of
legacy x86?

Andrew.

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

[H.J. Lu]

On Tue, Aug 3, 2010 at 2:37 AM, Andrew Haley <aph@redhat.com> wrote:
> On 08/03/2010 10:18 AM, Uros Bizjak wrote:
>> On Mon, Aug 2, 2010 at 7:54 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>>>> Here are the updated patch and spread sheet for SPEC CPU 2000/2006 on
>>>> Intel Core i7 which shows that -fomit-frame-pointer -fasynchronous-unwind-tables
>>>> improves performance by up to 12% at -O2 and 8% at -O3. For -Os, it improves
>>>> performance by up to 20%, but also increases code by up to 36%.
>>>>
>>>> This patch turns on -fomit-frame-pointer -fasynchronous-unwind-tables only if
>>>> -Os isn't used.
>>>>
>>>> Tested on Linux/ia32 and Linux/x86-64 with -m32. OK for trunk?
>>>
>>> Any comments on this patch.  Any objections?
>>
>> IMO, this should be approved by Release Managers, since this decision
>> affects distributions and their users.
>>
>> I have no _technical_ objections to this patch, but I won't approve it
>> either due to the reason above.
>
> It's hard for us to know all the use cases that this patch will break:
> there may be many users who unwind the stack by following the call
> chain, a technique that has worked for many years.  (And was even
> sanctioned by the ABI, wasn't it?)  We'll know when if push this patch
> out and hear the screams.

The psABI never guarantees it. If some code still depends on it today,
we know how to fix it.

> Is this really the right thing to do at this stage in the lifetime of
> legacy x86?

By the same token, it shouldn't be a big problem.

-- 
H.J.

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

[Daniel Jacobowitz]

On Tue, Aug 03, 2010 at 07:03:34AM -0700, H.J. Lu wrote:
> > It's hard for us to know all the use cases that this patch will break:
> > there may be many users who unwind the stack by following the call
> > chain, a technique that has worked for many years.  (And was even
> > sanctioned by the ABI, wasn't it?)  We'll know when if push this patch
> > out and hear the screams.
> 
> The psABI never guarantees it. If some code still depends on it today,
> we know how to fix it.

I don't consider this an acceptable position for GCC.  We have
probably millions of users on x86.  We can't make them update
their code because of an environmental change in GCC.  It's not
simple to update code that relies on the frame pointer, and my
experience on people porting from x86 to ARM or MIPS is that many
companies have code which relies on backtracing via the frame pointer.

I am opposed to the patch.

-- 
Daniel Jacobowitz
CodeSourcery

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

[H.J. Lu]

On Tue, Aug 3, 2010 at 7:18 AM, Daniel Jacobowitz <dan@codesourcery.com> wrote:
> On Tue, Aug 03, 2010 at 07:03:34AM -0700, H.J. Lu wrote:
>> > It's hard for us to know all the use cases that this patch will break:
>> > there may be many users who unwind the stack by following the call
>> > chain, a technique that has worked for many years.  (And was even
>> > sanctioned by the ABI, wasn't it?)  We'll know when if push this patch
>> > out and hear the screams.
>>
>> The psABI never guarantees it. If some code still depends on it today,
>> we know how to fix it.
>
> I don't consider this an acceptable position for GCC.  We have
> probably millions of users on x86.  We can't make them update
> their code because of an environmental change in GCC.  It's not
> simple to update code that relies on the frame pointer, and my
> experience on people porting from x86 to ARM or MIPS is that many
> companies have code which relies on backtracing via the frame pointer.
>

Their codes won't work on ARM/MIPS nor on x86 with other
compilers. If this is a real problem, they can always turn it off.
I don't think we hould punish majority of Linux/x86 users because
of it.


-- 
H.J.

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

[Daniel Jacobowitz]

On Tue, Aug 03, 2010 at 07:28:30AM -0700, H.J. Lu wrote:
> Their codes won't work on ARM/MIPS nor on x86 with other
> compilers. If this is a real problem, they can always turn it off.

It is a real problem, there are many cases of it, and it only works if
all the code in the system has frame pointers.  Unpleasant, but that's
the real world for you.  This is something that matters to a lot of users.

-- 
Daniel Jacobowitz
CodeSourcery

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

[H.J. Lu]

On Tue, Aug 3, 2010 at 8:13 AM, Daniel Jacobowitz <dan@codesourcery.com> wrote:
> On Tue, Aug 03, 2010 at 07:28:30AM -0700, H.J. Lu wrote:
>> Their codes won't work on ARM/MIPS nor on x86 with other
>> compilers. If this is a real problem, they can always turn it off.
>
> It is a real problem, there are many cases of it, and it only works if
> all the code in the system has frame pointers.  Unpleasant, but that's
> the real world for you.  This is something that matters to a lot of users.
>

Exactly. There is nothing there saying that all libraries on Linux/x86
must have frame pointers. On some systems, frame pointers are
omitted:

http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01128.html

There is nothing wrong with that.

-- 
H.J.

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

[H.J. Lu]

On Tue, Aug 3, 2010 at 2:18 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Mon, Aug 2, 2010 at 7:54 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>
>>> Here are the updated patch and spread sheet for SPEC CPU 2000/2006 on
>>> Intel Core i7 which shows that -fomit-frame-pointer -fasynchronous-unwind-tables
>>> improves performance by up to 12% at -O2 and 8% at -O3. For -Os, it improves
>>> performance by up to 20%, but also increases code by up to 36%.
>>>
>>> This patch turns on -fomit-frame-pointer -fasynchronous-unwind-tables only if
>>> -Os isn't used.
>>>
>>> Tested on Linux/ia32 and Linux/x86-64 with -m32. OK for trunk?
>>
>> Any comments on this patch.  Any objections?
>
> IMO, this should be approved by Release Managers, since this decision
> affects distributions and their users.
>
> I have no _technical_ objections to this patch, but I won't approve it
> either due to the reason above.
>

Richard, Jakub, Mark, do you have any comments?

Thanks.

-- 
H.J.

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

[Mark Mitchell]

H.J. Lu wrote:

> Richard, Jakub, Mark, do you have any comments?

I will review the thread today.  Please give me some time to comment.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

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

[Mark Mitchell]

Mark Mitchell wrote:

> I will review the thread today.  Please give me some time to comment.

I can certainly see both sides of this issue.

On the one hand, most users use "-O2" or "-O3", and we want those users
to see the best performance possible.  It's not reasonable to expect
that most users will figure out that they can use -fomit-frame-pointer
to improve performance and add it in.  My understanding is that some
distributions (e.g., OpenSuSE, IIUC) are now building the vast majority
of the distribution with -fomit-frame-pointer, but end users will not
necessarily know that they can/should use this option.  The bottom line
is that -O2 should maximize performance.

On the other, changing this default will undoubtedly cause pain.  As
Daniel said, we know that ARM and MIPS users have wrestled with the lack
of a frame pointer for some time.  There is a surprising amount of code
that has built-in unwinders of various kinds.  Being able to get
accurate backtraces from systems deployed in the field is essential for
many users.  This code will break, silently, and people will be unhappy.

If I could, I'd go back in time and eliminate ABIs that use frame
pointers.  The use of unwind tables is, IMHO, a clearly superior
solution.  It provides for superior performance, and, for users
uninterested in backtraces, smaller code.  (Even for users who do need
backtraces, it may result in a smaller cache footprint, since the unwind
tables will remain paged out most of the time.)  But, we are where we
are, and we can't go back.  So, the question is whether to make a
transition now, and, if so, how.

On balance, I think it's appropriate to make the change.  I think
there's an overall move towards ABIs without frame pointers, and that if
x86 stakeholders want to change, it's not our place as GCC maintainers
to do this.  The fact that major distributions are already building the
distribution itself (including its run-time libraries) without frame
pointers suggests that users must be adapting.  And the fact that ARM
and MIPS users are still developing software suggests that people are
learning how to deal with unwind tables.  So, it's a significant
transition, and there will be fallout, but it seems reasonable to me.

Ultimately, however, I don't think this is an RM question.  I think it
should be determined by the x86 back-end maintainers.  I'm happy to give
my input, and to help moderate a discussion if appropriate, but this
change does not affect any other architecture, so I think it's properly
a question for the x86 back-end maintainers.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

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

[Andrew Haley]

On 08/03/2010 06:12 PM, Mark Mitchell wrote:

> On balance, I think it's appropriate to make the change.  I think
> there's an overall move towards ABIs without frame pointers, and
> that if x86 stakeholders want to change, it's not our place as GCC
> maintainers to do this.

Thanks for the carefully considered reply.

A problem with "x86 stakeholders" is that we've historically been
rather poor at finding our users and consulting them before making
changes.  This has resulted in a number of flamewars, particularly
over type-based alias analysis.

I wonder if this might be an opportunity to create a new best practice
for gcc changes such as these by putting the decision out for
consultation.  I'm not quite sure how, though: obviously it's pretty
easy for me to get opinions from Red Hat, but there may be a great
many users we are totally unaware of.

Andrew.

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

[H.J. Lu]

On Tue, Aug 3, 2010 at 10:24 AM, Andrew Haley <aph@redhat.com> wrote:
> On 08/03/2010 06:12 PM, Mark Mitchell wrote:
>
>> On balance, I think it's appropriate to make the change.  I think
>> there's an overall move towards ABIs without frame pointers, and
>> that if x86 stakeholders want to change, it's not our place as GCC
>> maintainers to do this.
>
> Thanks for the carefully considered reply.
>
> A problem with "x86 stakeholders" is that we've historically been
> rather poor at finding our users and consulting them before making
> changes.  This has resulted in a number of flamewars, particularly
> over type-based alias analysis.
>
> I wonder if this might be an opportunity to create a new best practice
> for gcc changes such as these by putting the decision out for
> consultation.  I'm not quite sure how, though: obviously it's pretty
> easy for me to get opinions from Red Hat, but there may be a great
> many users we are totally unaware of.
>

We definitely should help our users deal with this change.
I only propose this for Linux/x86 where backstrace in glibc
supports unwind table. We can show them how to use
backstrace in glibc



-- 
H.J.

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

[Mark Mitchell]

Andrew Haley wrote:

>> On balance, I think it's appropriate to make the change.  I think
>> there's an overall move towards ABIs without frame pointers, and
>> that if x86 stakeholders want to change, it's not our place as GCC
>> maintainers to do this.

> A problem with "x86 stakeholders" is that we've historically been
> rather poor at finding our users and consulting them before making
> changes.  This has resulted in a number of flamewars, particularly
> over type-based alias analysis.

That's a general problem with free software: there are zillions of
users, and we don't know where they are or what they want.  I don't
think there's a really great way to solve this problem, though there's
no doubt an interesting Ph.D. thesis in there somewhere.

One thing we could do pretty easily is to ask some distributions whether
they will accept the change in defaults -- or undo it locally.  If, for
example, Red Hat product management is going to tweak the compiler so
that it's default is -fno-omit-frame-pointer, in order to maintain
backwards compatibility, then that's a valuable data point, since it
means that Red Hat believes its customers would be unhappy with the
change.  On the other hand, if Debian says that they'll happily go along
with the change, then that's a point in favor of making the change.

So, maybe we need a poll of some of the most popular x86 Linux
distributions, such as Debian, Red Hat, SuSe, and Ubuntu?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

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

[Andrew Haley]

On 08/03/2010 06:57 PM, Mark Mitchell wrote:
> Andrew Haley wrote:
> 
>>> On balance, I think it's appropriate to make the change.  I think
>>> there's an overall move towards ABIs without frame pointers, and
>>> that if x86 stakeholders want to change, it's not our place as GCC
>>> maintainers to do this.
> 
>> A problem with "x86 stakeholders" is that we've historically been
>> rather poor at finding our users and consulting them before making
>> changes.  This has resulted in a number of flamewars, particularly
>> over type-based alias analysis.
> 
> That's a general problem with free software: there are zillions of
> users, and we don't know where they are or what they want.  I don't
> think there's a really great way to solve this problem, though there's
> no doubt an interesting Ph.D. thesis in there somewhere.
> 
> One thing we could do pretty easily is to ask some distributions whether
> they will accept the change in defaults -- or undo it locally.  If, for
> example, Red Hat product management is going to tweak the compiler so
> that it's default is -fno-omit-frame-pointer, in order to maintain
> backwards compatibility, then that's a valuable data point, since it
> means that Red Hat believes its customers would be unhappy with the
> change.  On the other hand, if Debian says that they'll happily go along
> with the change, then that's a point in favor of making the change.
> 
> So, maybe we need a poll of some of the most popular x86 Linux
> distributions, such as Debian, Red Hat, SuSe, and Ubuntu?

I propose to raise this matter on the LKML.  Does anyone think this
would be a bad idea?

Andrew.

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

[Mark Mitchell]

Andrew Haley wrote:

>> So, maybe we need a poll of some of the most popular x86 Linux
>> distributions, such as Debian, Red Hat, SuSe, and Ubuntu?
> 
> I propose to raise this matter on the LKML.  Does anyone think this
> would be a bad idea?

You certainly don't need permission to raise the issue where you think
might be helpful.  But, is LKML a particularly good place?  This issue
isn't going to affect kernel developers; my understanding is that the
kernel still needs frame pointers, but whether or not it does, the
kernel people will put the right option in their Makefiles.  This is
really a question for userspace developers, with their uncountably vast
number of applications and libraries.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

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

[Andrew Haley]

On 08/04/2010 03:29 PM, Mark Mitchell wrote:
> Andrew Haley wrote:
> 
>>> So, maybe we need a poll of some of the most popular x86 Linux
>>> distributions, such as Debian, Red Hat, SuSe, and Ubuntu?
>>
>> I propose to raise this matter on the LKML.  Does anyone think this
>> would be a bad idea?
> 
> You certainly don't need permission to raise the issue where you
> think might be helpful.  But, is LKML a particularly good place?
> This issue isn't going to affect kernel developers; my understanding
> is that the kernel still needs frame pointers, but whether or not it
> does, the kernel people will put the right option in their
> Makefiles.  This is really a question for userspace developers, with
> their uncountably vast number of applications and libraries.

Well, LKML would be a starting place, and they are a group of users
that has screamed about such changes in the past.  However, I take
your point.

Perhaps fedora-devel would be a good place for me to start: it's in my
back yard, anyway.

Andrew.

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

[Bernd Schmidt]

On 08/04/2010 04:29 PM, Mark Mitchell wrote:
> But, is LKML a particularly good place?  This issue
> isn't going to affect kernel developers; my understanding is that the
> kernel still needs frame pointers, but whether or not it does, the
> kernel people will put the right option in their Makefiles.

config FRAME_POINTER
        bool "Compile the kernel with frame pointers"
        depends on DEBUG_KERNEL && \
                (X86 || CRIS || M68K || M68KNOMMU || FRV || UML || S390 || \
                 AVR32 || SUPERH || BLACKFIN || MN10300)
        default y if DEBUG_INFO && UML
        help
          If you say Y here the resulting kernel image will be slightly
larger
          and slower, but it might give very useful debugging information on
          some architectures or if you use external debuggers.
          If you don't debug the kernel, you can say N.


Bernd

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

[Jan Hubicka]

> Andrew Haley wrote:
> 
> >> On balance, I think it's appropriate to make the change.  I think
> >> there's an overall move towards ABIs without frame pointers, and
> >> that if x86 stakeholders want to change, it's not our place as GCC
> >> maintainers to do this.
> 
> > A problem with "x86 stakeholders" is that we've historically been
> > rather poor at finding our users and consulting them before making
> > changes.  This has resulted in a number of flamewars, particularly
> > over type-based alias analysis.
> 
> That's a general problem with free software: there are zillions of
> users, and we don't know where they are or what they want.  I don't
> think there's a really great way to solve this problem, though there's
> no doubt an interesting Ph.D. thesis in there somewhere.
> 
> One thing we could do pretty easily is to ask some distributions whether
> they will accept the change in defaults -- or undo it locally.  If, for
> example, Red Hat product management is going to tweak the compiler so
> that it's default is -fno-omit-frame-pointer, in order to maintain
> backwards compatibility, then that's a valuable data point, since it
> means that Red Hat believes its customers would be unhappy with the
> change.  On the other hand, if Debian says that they'll happily go along
> with the change, then that's a point in favor of making the change.
> 
> So, maybe we need a poll of some of the most popular x86 Linux
> distributions, such as Debian, Red Hat, SuSe, and Ubuntu?

I went through the defualt changing discussion at a time we was introducing
x86-64 port.
In general, I believe -fomit-frame-pointer by default is win. x86-64
defaults to this for a while and thus the pain of switching should be limited,
since most of packages adopted to 64bit world. 

Probably the most touchy issue concerning the switch is place where you need
stack unwinding fast.  This is the case of oprofile and some of garbage collector
implementations.

Honza
> 
> -- 
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713

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

[Andrew Haley]

On 08/04/2010 03:59 PM, Jan Hubicka wrote:
>>
>> So, maybe we need a poll of some of the most popular x86 Linux
>> distributions, such as Debian, Red Hat, SuSe, and Ubuntu?
> 
> I went through the defualt changing discussion at a time we was introducing
> x86-64 port.
> In general, I believe -fomit-frame-pointer by default is win. x86-64
> defaults to this for a while and thus the pain of switching should be limited,
> since most of packages adopted to 64bit world. 

I don't dispute that this is the best default for all new arches.  However,
32-bit x86 is a legacy arch, with a lot of dusty old code.

> Probably the most touchy issue concerning the switch is place where you need
> stack unwinding fast.  This is the case of oprofile and some of garbage collector
> implementations.

Ah, yes.

Andrew.

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

[H.J. Lu]

On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> Andrew Haley wrote:
>>
>> >> On balance, I think it's appropriate to make the change.  I think
>> >> there's an overall move towards ABIs without frame pointers, and
>> >> that if x86 stakeholders want to change, it's not our place as GCC
>> >> maintainers to do this.
>>
>> > A problem with "x86 stakeholders" is that we've historically been
>> > rather poor at finding our users and consulting them before making
>> > changes.  This has resulted in a number of flamewars, particularly
>> > over type-based alias analysis.
>>
>> That's a general problem with free software: there are zillions of
>> users, and we don't know where they are or what they want.  I don't
>> think there's a really great way to solve this problem, though there's
>> no doubt an interesting Ph.D. thesis in there somewhere.
>>
>> One thing we could do pretty easily is to ask some distributions whether
>> they will accept the change in defaults -- or undo it locally.  If, for
>> example, Red Hat product management is going to tweak the compiler so
>> that it's default is -fno-omit-frame-pointer, in order to maintain
>> backwards compatibility, then that's a valuable data point, since it
>> means that Red Hat believes its customers would be unhappy with the
>> change.  On the other hand, if Debian says that they'll happily go along
>> with the change, then that's a point in favor of making the change.
>>
>> So, maybe we need a poll of some of the most popular x86 Linux
>> distributions, such as Debian, Red Hat, SuSe, and Ubuntu?
>
> I went through the defualt changing discussion at a time we was introducing
> x86-64 port.
> In general, I believe -fomit-frame-pointer by default is win. x86-64
> defaults to this for a while and thus the pain of switching should be limited,
> since most of packages adopted to 64bit world.
>
> Probably the most touchy issue concerning the switch is place where you need
> stack unwinding fast.  This is the case of oprofile and some of garbage collector
> implementations.
>

Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
As for "some garbage collector implementations", do they work on
Linux/x86-64? Do they work with icc on 32bit Linux/x86?

-- 
H.J.

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

[Andrew Haley]

On 08/04/2010 05:08 PM, H.J. Lu wrote:
> On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>> Andrew Haley wrote:
>>>
>>>>> On balance, I think it's appropriate to make the change.  I think
>>>>> there's an overall move towards ABIs without frame pointers, and
>>>>> that if x86 stakeholders want to change, it's not our place as GCC
>>>>> maintainers to do this.
>>>
>>>> A problem with "x86 stakeholders" is that we've historically been
>>>> rather poor at finding our users and consulting them before making
>>>> changes.  This has resulted in a number of flamewars, particularly
>>>> over type-based alias analysis.
>>>
>>> That's a general problem with free software: there are zillions of
>>> users, and we don't know where they are or what they want.  I don't
>>> think there's a really great way to solve this problem, though there's
>>> no doubt an interesting Ph.D. thesis in there somewhere.
>>>
>>> One thing we could do pretty easily is to ask some distributions whether
>>> they will accept the change in defaults -- or undo it locally.  If, for
>>> example, Red Hat product management is going to tweak the compiler so
>>> that it's default is -fno-omit-frame-pointer, in order to maintain
>>> backwards compatibility, then that's a valuable data point, since it
>>> means that Red Hat believes its customers would be unhappy with the
>>> change.  On the other hand, if Debian says that they'll happily go along
>>> with the change, then that's a point in favor of making the change.
>>>
>>> So, maybe we need a poll of some of the most popular x86 Linux
>>> distributions, such as Debian, Red Hat, SuSe, and Ubuntu?
>>
>> I went through the defualt changing discussion at a time we was introducing
>> x86-64 port.
>> In general, I believe -fomit-frame-pointer by default is win. x86-64
>> defaults to this for a while and thus the pain of switching should be limited,
>> since most of packages adopted to 64bit world.
>>
>> Probably the most touchy issue concerning the switch is place where you need
>> stack unwinding fast.  This is the case of oprofile and some of garbage collector
>> implementations.
>>
> 
> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.

I'll ask.

> As for "some garbage collector implementations", do they work on
> Linux/x86-64? Do they work with icc on 32bit Linux/x86?
> 

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

[Andrew Haley]

On 08/04/2010 05:22 PM, Andrew Haley wrote:
> On 08/04/2010 05:08 PM, H.J. Lu wrote:
>> On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>
>>> I went through the defualt changing discussion at a time we was introducing
>>> x86-64 port.
>>> In general, I believe -fomit-frame-pointer by default is win. x86-64
>>> defaults to this for a while and thus the pain of switching should be limited,
>>> since most of packages adopted to 64bit world.
>>>
>>> Probably the most touchy issue concerning the switch is place
>>> where you need stack unwinding fast.  This is the case of oprofile
>>> and some of garbage collector implementations.
>>
>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
> 
> I'll ask.

For oprofile the answer is "Oprofile has a very simple-minded
mechanism that uses the frame pointers to walk the stack. If the frame
pointers are turned off, the call graph information oprofile generates
will be pretty limited. The flat profiling will still work fine."

Andrew.

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

[Andrew Haley]

On 08/04/2010 06:05 PM, Andrew Haley wrote:
> On 08/04/2010 05:22 PM, Andrew Haley wrote:
>> On 08/04/2010 05:08 PM, H.J. Lu wrote:
>>> On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>>
>>>> I went through the defualt changing discussion at a time we was introducing
>>>> x86-64 port.
>>>> In general, I believe -fomit-frame-pointer by default is win. x86-64
>>>> defaults to this for a while and thus the pain of switching should be limited,
>>>> since most of packages adopted to 64bit world.
>>>>
>>>> Probably the most touchy issue concerning the switch is place
>>>> where you need stack unwinding fast.  This is the case of oprofile
>>>> and some of garbage collector implementations.
>>>
>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
>>
>> I'll ask.
> 
> For oprofile the answer is "Oprofile has a very simple-minded
> mechanism that uses the frame pointers to walk the stack. If the frame
> pointers are turned off, the call graph information oprofile generates
> will be pretty limited. The flat profiling will still work fine."

And for systemtap and java:

"systemtap uses .eh_frame/.debug_frame unwind info to get backtraces
(both kernel and user space), so that should be fine with/without
framepointers (but kind of relies on -fasynchronous-unwind-tables, which
is the default on fedora/rhel). The jstack support for hotspot relies on
frame_pointers being generated by the JITs (which isn't always true, but
it can often recover when it finds a frame that doesn't have one)."

Andrew.

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

[H.J. Lu]

On Wed, Aug 4, 2010 at 10:06 AM, Andrew Haley <aph@redhat.com> wrote:
> On 08/04/2010 06:05 PM, Andrew Haley wrote:
>> On 08/04/2010 05:22 PM, Andrew Haley wrote:
>>> On 08/04/2010 05:08 PM, H.J. Lu wrote:
>>>> On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>>>
>>>>> I went through the defualt changing discussion at a time we was introducing
>>>>> x86-64 port.
>>>>> In general, I believe -fomit-frame-pointer by default is win. x86-64
>>>>> defaults to this for a while and thus the pain of switching should be limited,
>>>>> since most of packages adopted to 64bit world.
>>>>>
>>>>> Probably the most touchy issue concerning the switch is place
>>>>> where you need stack unwinding fast.  This is the case of oprofile
>>>>> and some of garbage collector implementations.
>>>>
>>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
>>>
>>> I'll ask.
>>
>> For oprofile the answer is "Oprofile has a very simple-minded
>> mechanism that uses the frame pointers to walk the stack. If the frame
>> pointers are turned off, the call graph information oprofile generates
>> will be pretty limited. The flat profiling will still work fine."
>
> And for systemtap and java:
>
> "systemtap uses .eh_frame/.debug_frame unwind info to get backtraces
> (both kernel and user space), so that should be fine with/without
> framepointers (but kind of relies on -fasynchronous-unwind-tables, which
> is the default on fedora/rhel). The jstack support for hotspot relies on
> frame_pointers being generated by the JITs (which isn't always true, but
> it can often recover when it finds a frame that doesn't have one)."
>

Does jstack work on Linux/x86-64?


-- 
H.J.

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

[Mark Wielaard]

H.J. Lu <hjl.tools <at> gmail.com> writes:
> On Wed, Aug 4, 2010 at 10:06 AM, Andrew Haley <aph <at> redhat.com> wrote:
> > On 08/04/2010 06:05 PM, Andrew Haley wrote:
> > And for systemtap and java:
> >
> > "systemtap uses .eh_frame/.debug_frame unwind info to get backtraces
> > (both kernel and user space), so that should be fine with/without
> > framepointers (but kind of relies on -fasynchronous-unwind-tables, which
> > is the default on fedora/rhel). The jstack support for hotspot relies on
> > frame_pointers being generated by the JITs (which isn't always true, but
> > it can often recover when it finds a frame that doesn't have one)."
> >
> 
> Does jstack work on Linux/x86-64?

Yes. The systemtap jstack support relies on the code generated by the java
hotspot code generator. It walks "java frames". So it doesn't matter (much) what
gcc generated itself. In theory it would break down if a non-java frame sneaks
in without an explicit frame-pointer (like JNI code). gcc on x86_64 doesn't
generate them, but we haven't heard much complains (jstack tries to recover and
guess the next stack frame). If there are complaints it is too unreliable jstack
might be extended to find/use the (java) stack frame data from the hotspot
runtime (which already has to deal with unwinding through mixed java/native code
without frame-pointers. Or it could try reusing the systemtap support for
walking the user stack through CFIs for those "native" frames.

Cheers,

Mark

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

[H.J. Lu]

On Wed, Aug 4, 2010 at 10:05 AM, Andrew Haley <aph@redhat.com> wrote:
> On 08/04/2010 05:22 PM, Andrew Haley wrote:
>> On 08/04/2010 05:08 PM, H.J. Lu wrote:
>>> On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>>
>>>> I went through the defualt changing discussion at a time we was introducing
>>>> x86-64 port.
>>>> In general, I believe -fomit-frame-pointer by default is win. x86-64
>>>> defaults to this for a while and thus the pain of switching should be limited,
>>>> since most of packages adopted to 64bit world.
>>>>
>>>> Probably the most touchy issue concerning the switch is place
>>>> where you need stack unwinding fast.  This is the case of oprofile
>>>> and some of garbage collector implementations.
>>>
>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
>>
>> I'll ask.
>
> For oprofile the answer is "Oprofile has a very simple-minded
> mechanism that uses the frame pointers to walk the stack. If the frame
> pointers are turned off, the call graph information oprofile generates
> will be pretty limited. The flat profiling will still work fine."
>

Does oprofile work on Linux/x86-64? If yes, how does it walk the stack?


-- 
H.J.

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

[Andrew Haley]

On 08/04/2010 06:07 PM, H.J. Lu wrote:
> On Wed, Aug 4, 2010 at 10:05 AM, Andrew Haley <aph@redhat.com> wrote:
>> On 08/04/2010 05:22 PM, Andrew Haley wrote:
>>> On 08/04/2010 05:08 PM, H.J. Lu wrote:
>>>> On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>>>
>>>>> I went through the defualt changing discussion at a time we was introducing
>>>>> x86-64 port.
>>>>> In general, I believe -fomit-frame-pointer by default is win. x86-64
>>>>> defaults to this for a while and thus the pain of switching should be limited,
>>>>> since most of packages adopted to 64bit world.
>>>>>
>>>>> Probably the most touchy issue concerning the switch is place
>>>>> where you need stack unwinding fast.  This is the case of oprofile
>>>>> and some of garbage collector implementations.
>>>>
>>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
>>>
>>> I'll ask.
>>
>> For oprofile the answer is "Oprofile has a very simple-minded
>> mechanism that uses the frame pointers to walk the stack. If the frame
>> pointers are turned off, the call graph information oprofile generates
>> will be pretty limited. The flat profiling will still work fine."
> 
> Does oprofile work on Linux/x86-64? If yes, how does it walk the stack?

Call graph information doesn't work on x86-64.

Andrew.

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

[H.J. Lu]

On Wed, Aug 4, 2010 at 10:09 AM, Andrew Haley <aph@redhat.com> wrote:
> On 08/04/2010 06:07 PM, H.J. Lu wrote:
>> On Wed, Aug 4, 2010 at 10:05 AM, Andrew Haley <aph@redhat.com> wrote:
>>> On 08/04/2010 05:22 PM, Andrew Haley wrote:
>>>> On 08/04/2010 05:08 PM, H.J. Lu wrote:
>>>>> On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>>>>
>>>>>> I went through the defualt changing discussion at a time we was introducing
>>>>>> x86-64 port.
>>>>>> In general, I believe -fomit-frame-pointer by default is win. x86-64
>>>>>> defaults to this for a while and thus the pain of switching should be limited,
>>>>>> since most of packages adopted to 64bit world.
>>>>>>
>>>>>> Probably the most touchy issue concerning the switch is place
>>>>>> where you need stack unwinding fast.  This is the case of oprofile
>>>>>> and some of garbage collector implementations.
>>>>>
>>>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
>>>>
>>>> I'll ask.
>>>
>>> For oprofile the answer is "Oprofile has a very simple-minded
>>> mechanism that uses the frame pointers to walk the stack. If the frame
>>> pointers are turned off, the call graph information oprofile generates
>>> will be pretty limited. The flat profiling will still work fine."
>>
>> Does oprofile work on Linux/x86-64? If yes, how does it walk the stack?
>
> Call graph information doesn't work on x86-64.
>

So we get the same info as on Linux/x86-64. If it works on Linux/x86-64
in the future, it can also work on Linux/ia32 with -fomit-frame-pointer.


-- 
H.J.

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

[Andrew Haley]

On 08/04/2010 06:12 PM, H.J. Lu wrote:
> On Wed, Aug 4, 2010 at 10:09 AM, Andrew Haley <aph@redhat.com> wrote:
>> On 08/04/2010 06:07 PM, H.J. Lu wrote:
>>> On Wed, Aug 4, 2010 at 10:05 AM, Andrew Haley <aph@redhat.com> wrote:
>>>> On 08/04/2010 05:22 PM, Andrew Haley wrote:
>>>>> On 08/04/2010 05:08 PM, H.J. Lu wrote:
>>>>>> On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>>>>>
>>>>>>> I went through the defualt changing discussion at a time we was introducing
>>>>>>> x86-64 port.
>>>>>>> In general, I believe -fomit-frame-pointer by default is win. x86-64
>>>>>>> defaults to this for a while and thus the pain of switching should be limited,
>>>>>>> since most of packages adopted to 64bit world.
>>>>>>>
>>>>>>> Probably the most touchy issue concerning the switch is place
>>>>>>> where you need stack unwinding fast.  This is the case of oprofile
>>>>>>> and some of garbage collector implementations.
>>>>>>
>>>>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
>>>>>
>>>>> I'll ask.
>>>>
>>>> For oprofile the answer is "Oprofile has a very simple-minded
>>>> mechanism that uses the frame pointers to walk the stack. If the frame
>>>> pointers are turned off, the call graph information oprofile generates
>>>> will be pretty limited. The flat profiling will still work fine."
>>>
>>> Does oprofile work on Linux/x86-64? If yes, how does it walk the stack?
>>
>> Call graph information doesn't work on x86-64.
> 
> So we get the same info as on Linux/x86-64. If it works on Linux/x86-64
> in the future, it can also work on Linux/ia32 with -fomit-frame-pointer.

Yes.  I'm not really sure what point you're trying to make, though: it
seems to be "x86-64 profiling is degraded, so we might as well degrade
x86 as well."  But that doesn't make any sense, so that can't be what
you mean.

Andrew.

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

[H.J. Lu]

On Wed, Aug 4, 2010 at 10:15 AM, Andrew Haley <aph@redhat.com> wrote:
> On 08/04/2010 06:12 PM, H.J. Lu wrote:
>> On Wed, Aug 4, 2010 at 10:09 AM, Andrew Haley <aph@redhat.com> wrote:
>>> On 08/04/2010 06:07 PM, H.J. Lu wrote:
>>>> On Wed, Aug 4, 2010 at 10:05 AM, Andrew Haley <aph@redhat.com> wrote:
>>>>> On 08/04/2010 05:22 PM, Andrew Haley wrote:
>>>>>> On 08/04/2010 05:08 PM, H.J. Lu wrote:
>>>>>>> On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>>>>>>
>>>>>>>> I went through the defualt changing discussion at a time we was introducing
>>>>>>>> x86-64 port.
>>>>>>>> In general, I believe -fomit-frame-pointer by default is win. x86-64
>>>>>>>> defaults to this for a while and thus the pain of switching should be limited,
>>>>>>>> since most of packages adopted to 64bit world.
>>>>>>>>
>>>>>>>> Probably the most touchy issue concerning the switch is place
>>>>>>>> where you need stack unwinding fast.  This is the case of oprofile
>>>>>>>> and some of garbage collector implementations.
>>>>>>>
>>>>>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
>>>>>>
>>>>>> I'll ask.
>>>>>
>>>>> For oprofile the answer is "Oprofile has a very simple-minded
>>>>> mechanism that uses the frame pointers to walk the stack. If the frame
>>>>> pointers are turned off, the call graph information oprofile generates
>>>>> will be pretty limited. The flat profiling will still work fine."
>>>>
>>>> Does oprofile work on Linux/x86-64? If yes, how does it walk the stack?
>>>
>>> Call graph information doesn't work on x86-64.
>>
>> So we get the same info as on Linux/x86-64. If it works on Linux/x86-64
>> in the future, it can also work on Linux/ia32 with -fomit-frame-pointer.
>
> Yes.  I'm not really sure what point you're trying to make, though: it
> seems to be "x86-64 profiling is degraded, so we might as well degrade
> x86 as well."  But that doesn't make any sense, so that can't be what
> you mean.
>

What I was trying to say are:

1. We chose to degrade x86-64 profiling for performance and it isn't
a big problem so that we want to compile x86-64 with -fno-omit-frame-pointer.
2. If we can do this for x86-64, we can also do it for ia32.
3. The unwind info is there and we can get it if we really want it.



-- 
H.J.

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

[Chris Lattner]

On Aug 4, 2010, at 10:05 AM, Andrew Haley wrote:

> On 08/04/2010 05:22 PM, Andrew Haley wrote:
>> On 08/04/2010 05:08 PM, H.J. Lu wrote:
>>> On Wed, Aug 4, 2010 at 7:59 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>>> 
>>>> I went through the defualt changing discussion at a time we was introducing
>>>> x86-64 port.
>>>> In general, I believe -fomit-frame-pointer by default is win. x86-64
>>>> defaults to this for a while and thus the pain of switching should be limited,
>>>> since most of packages adopted to 64bit world.
>>>> 
>>>> Probably the most touchy issue concerning the switch is place
>>>> where you need stack unwinding fast.  This is the case of oprofile
>>>> and some of garbage collector implementations.
>>> 
>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
>> 
>> I'll ask.
> 
> For oprofile the answer is "Oprofile has a very simple-minded
> mechanism that uses the frame pointers to walk the stack. If the frame
> pointers are turned off, the call graph information oprofile generates
> will be pretty limited. The flat profiling will still work fine."

FWIW, this is one of the main reasons why Darwin/i386 still uses frame pointers for the whole OS stack.  The kernel based profiler (shark) doesn't want to grovel through eh frame info from kernel space.  This means that -fomit-frame-pointers severely harms whole-system profiling on i386, which was considered unacceptable.

-Chris

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

[Andi Kleen]

"H.J. Lu" <hjl.tools@gmail.com> writes:
>
> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.

It doesn't for user space. The problem is that you would need
an in kernel dwarf2 unwinder that reads user space tables. 

x86-64 suffers from this already.

However there are some alternative approaches being explored for this,
like using LBRs. 

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

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

[H.J. Lu]

On Wed, Aug 4, 2010 at 10:35 AM, Andi Kleen <andi@firstfloor.org> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>
>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
>
> It doesn't for user space. The problem is that you would need
> an in kernel dwarf2 unwinder that reads user space tables.
>
> x86-64 suffers from this already.
>

But it is considered acceptable so that we still want -fomit-frame-pointer
for Linux/x86-64.


-- 
H.J.

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

[Andrew Haley]

On 08/04/2010 06:41 PM, H.J. Lu wrote:
> On Wed, Aug 4, 2010 at 10:35 AM, Andi Kleen <andi@firstfloor.org> wrote:
>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>>
>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
>>
>> It doesn't for user space. The problem is that you would need
>> an in kernel dwarf2 unwinder that reads user space tables.
>>
>> x86-64 suffers from this already.
> 

> But it is considered acceptable

By whom?

> so that we still want -fomit-frame-pointer for Linux/x86-64.

Ah, so your argument *is* "x86-64 profiling is degraded, so we might
as well degrade x86 as well."

Andrew.

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

[H.J. Lu]

On Wed, Aug 4, 2010 at 10:47 AM, Andrew Haley <aph@redhat.com> wrote:
> On 08/04/2010 06:41 PM, H.J. Lu wrote:
>> On Wed, Aug 4, 2010 at 10:35 AM, Andi Kleen <andi@firstfloor.org> wrote:
>>> "H.J. Lu" <hjl.tools@gmail.com> writes:
>>>>
>>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
>>>
>>> It doesn't for user space. The problem is that you would need
>>> an in kernel dwarf2 unwinder that reads user space tables.
>>>
>>> x86-64 suffers from this already.
>>
>
>> But it is considered acceptable
>
> By whom?

By people's action.

>
>> so that we still want -fomit-frame-pointer for Linux/x86-64.
>
> Ah, so your argument *is* "x86-64 profiling is degraded, so we might
> as well degrade x86 as well."
>

Yes, especially when it gives some nice performance improvement.
Can you tell me which gcc optimization can give you 4% speedup
in most applications?


-- 
H.J.

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

[Andi Kleen]

On Wed, Aug 04, 2010 at 06:47:19PM +0100, Andrew Haley wrote:
> On 08/04/2010 06:41 PM, H.J. Lu wrote:
> > On Wed, Aug 4, 2010 at 10:35 AM, Andi Kleen <andi@firstfloor.org> wrote:
> >> "H.J. Lu" <hjl.tools@gmail.com> writes:
> >>>
> >>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
> >>
> >> It doesn't for user space. The problem is that you would need
> >> an in kernel dwarf2 unwinder that reads user space tables.
> >>
> >> x86-64 suffers from this already.
> > 
> 
> > But it is considered acceptable
> 
> By whom?
> 
> > so that we still want -fomit-frame-pointer for Linux/x86-64.
> 
> Ah, so your argument *is* "x86-64 profiling is degraded, so we might
> as well degrade x86 as well."

It's not a totally unreasonable argument.

The right action would be probably to attack the problem properly for both.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

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

[Mark Mitchell]

Andi Kleen wrote:

>> Ah, so your argument *is* "x86-64 profiling is degraded, so we might
>> as well degrade x86 as well."
> 
> It's not a totally unreasonable argument.

I agree; you can reason as follows:

* We are not going to change the 64-bit ABI.
* We really want profiling to work on the 64-bit ABI.
* Therefore, we must fix profiling for the 64-bit ABI so that it works
well without a frame pointer.
* That solution will probably work well on the 32-bit ABI too.

But, then there is a reasonable question about ordering.  If that's the
plan, then perhaps profiling should be fixed first, so that 32-bit users
don't lose that ability until someone gets around to fixing profiling
without a frame pointer.  On the other hand, maybe 32-bit users would
like their performance increase now.

HJ, I don't think your arguments are persuasive in themselves.  There is
not a completely obvious right answer here and simply tossing out the
same arguments doesn't make them more obviously right.  This is a
question about what's good for users; whether they benefit more by the
performance improvement than they lose by the change in ABI and code
breakage and associated loss of functionality.

My instinct on this issue remains that we should make the change, but I
don't claim that's obvious.  The only way I can see to get a scientific
answer (as opposed to "my instinct is" answer) is to talk to actual users.

Please either go do that, or else let's ask RTH, Uros, and Jan to vote;
we've got three x86 maintainers, so if they all vote, we can't have a tie...

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

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

[H.J. Lu]

On Wed, Aug 4, 2010 at 11:11 AM, Mark Mitchell <mark@codesourcery.com> wrote:
> Andi Kleen wrote:
>
>>> Ah, so your argument *is* "x86-64 profiling is degraded, so we might
>>> as well degrade x86 as well."
>>
>> It's not a totally unreasonable argument.
>
> I agree; you can reason as follows:
>
> * We are not going to change the 64-bit ABI.
> * We really want profiling to work on the 64-bit ABI.
> * Therefore, we must fix profiling for the 64-bit ABI so that it works
> well without a frame pointer.
> * That solution will probably work well on the 32-bit ABI too.
>
> But, then there is a reasonable question about ordering.  If that's the
> plan, then perhaps profiling should be fixed first, so that 32-bit users
> don't lose that ability until someone gets around to fixing profiling
> without a frame pointer.  On the other hand, maybe 32-bit users would
> like their performance increase now.
>
> HJ, I don't think your arguments are persuasive in themselves.  There is
> not a completely obvious right answer here and simply tossing out the
> same arguments doesn't make them more obviously right.  This is a
> question about what's good for users; whether they benefit more by the
> performance improvement than they lose by the change in ABI and code
> breakage and associated loss of functionality.
>
> My instinct on this issue remains that we should make the change, but I
> don't claim that's obvious.  The only way I can see to get a scientific
> answer (as opposed to "my instinct is" answer) is to talk to actual users.

ICC has made -fomit-frame-pointer the default on 32bit for a quite while. I can
ask ICC people if they have any complaints from their users.

> Please either go do that, or else let's ask RTH, Uros, and Jan to vote;
> we've got three x86 maintainers, so if they all vote, we can't have a tie...
>

That sounds a good idea.

-- 
H.J.

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

[Maciej W. Rozycki]

On Wed, 4 Aug 2010, Andi Kleen wrote:

> > Can we find if oprofile works with -fomit-frame-pointer on 32bit Linux/x86.
> 
> It doesn't for user space. The problem is that you would need
> an in kernel dwarf2 unwinder that reads user space tables. 
> 
> x86-64 suffers from this already.
> 
> However there are some alternative approaches being explored for this,
> like using LBRs. 

 I don't know what a LBR is, but FWIW, it looks to me like a scenario 
asking for a userspace daemon interpreting raw address/stack information 
passed on from the kernel.  The daemon could use whatever complex tools 
are needed to interpret the information received or just dump it somewhere 
in a form complete enough for later post-processing (e.g. if the tools 
required were not fast enough to cope in real time).

 Just because while in some cases it seems easier to code (hack) things 
into the kernel, it does not necessarily mean they should be there.  The 
fewer things in the kernel the better.  Just IMHO.

  Maciej

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

[David Daney]

On 08/03/2010 10:24 AM, Andrew Haley wrote:
> On 08/03/2010 06:12 PM, Mark Mitchell wrote:
>
>> On balance, I think it's appropriate to make the change.  I think
>> there's an overall move towards ABIs without frame pointers, and
>> that if x86 stakeholders want to change, it's not our place as GCC
>> maintainers to do this.
>
> Thanks for the carefully considered reply.
>
> A problem with "x86 stakeholders" is that we've historically been
> rather poor at finding our users and consulting them before making
> changes.  This has resulted in a number of flamewars, particularly
> over type-based alias analysis.
>

It may even be possible to preemptively generate a flamewar with a post 
to something like the LKML laying out the pros and cons.

It is a change to the de facto ABI.  Think back to what happened with 
the x86 direction flag issue.


David Daney

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

[H.J. Lu]

Hi Mark,

Thanks for your inputs.

On Tue, Aug 3, 2010 at 10:12 AM, Mark Mitchell <mark@codesourcery.com> wrote:
> Mark Mitchell wrote:
>
>> I will review the thread today.  Please give me some time to comment.
>
> I can certainly see both sides of this issue.
>
> On the one hand, most users use "-O2" or "-O3", and we want those users
> to see the best performance possible.  It's not reasonable to expect
> that most users will figure out that they can use -fomit-frame-pointer
> to improve performance and add it in.  My understanding is that some
> distributions (e.g., OpenSuSE, IIUC) are now building the vast majority
> of the distribution with -fomit-frame-pointer, but end users will not
> necessarily know that they can/should use this option.  The bottom line
> is that -O2 should maximize performance.
>
> On the other, changing this default will undoubtedly cause pain.  As
> Daniel said, we know that ARM and MIPS users have wrestled with the lack
> of a frame pointer for some time.  There is a surprising amount of code
> that has built-in unwinders of various kinds.  Being able to get
> accurate backtraces from systems deployed in the field is essential for
> many users.  This code will break, silently, and people will be unhappy.
>
> If I could, I'd go back in time and eliminate ABIs that use frame
> pointers.  The use of unwind tables is, IMHO, a clearly superior

Just for the reference, this is from i386 psABI:

---
%ebp  The frame pointer optionally holds a base address for the current
           stack frame. Consequently, a function has registers pointing to
           both ends of its frame. Incoming arguments reside in the previous
           frame, referenced as positive offsets from %ebp, while local
           variables reside in the current frame, referenced as negative
           offsets from %ebp. A function must preserve this register’s value
           for its caller.
---

The stack layout at function entry is the same as x86-64 psABI. I understand
the old backtrace codes depend on the frame pointer, but it isn't mandated
by the psABI.

> solution.  It provides for superior performance, and, for users
> uninterested in backtraces, smaller code.  (Even for users who do need
> backtraces, it may result in a smaller cache footprint, since the unwind
> tables will remain paged out most of the time.)  But, we are where we
> are, and we can't go back.  So, the question is whether to make a
> transition now, and, if so, how.
>
> On balance, I think it's appropriate to make the change.  I think
> there's an overall move towards ABIs without frame pointers, and that if
> x86 stakeholders want to change, it's not our place as GCC maintainers
> to do this.  The fact that major distributions are already building the
> distribution itself (including its run-time libraries) without frame
> pointers suggests that users must be adapting.  And the fact that ARM
> and MIPS users are still developing software suggests that people are
> learning how to deal with unwind tables.  So, it's a significant
> transition, and there will be fallout, but it seems reasonable to me.
>
> Ultimately, however, I don't think this is an RM question.  I think it
> should be determined by the x86 back-end maintainers.  I'm happy to give
> my input, and to help moderate a discussion if appropriate, but this
> change does not affect any other architecture, so I think it's properly
> a question for the x86 back-end maintainers.
>

Thanks.


-- 
H.J.

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

[Mark Mitchell]

H.J. Lu wrote:

>> If I could, I'd go back in time and eliminate ABIs that use frame
>> pointers.  The use of unwind tables is, IMHO, a clearly superior

> The stack layout at function entry is the same as x86-64 psABI. I understand
> the old backtrace codes depend on the frame pointer, but it isn't mandated
> by the psABI.

Sure, but the psABI document is less relevant than existing practice.  I
don't think it's relevant to this discussion.  Let's not talk about it.

The important issue is that there is a lot of code out there that
probably assumes a frame pointer, and it will stop working.  We have to
weigh that against the fact that the code that doesn't stop working will
run faster.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

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

[Richard Henderson]

On 08/03/2010 10:12 AM, Mark Mitchell wrote:
> Ultimately, however, I don't think this is an RM question.  I think it
> should be determined by the x86 back-end maintainers.  I'm happy to give
> my input, and to help moderate a discussion if appropriate, but this
> change does not affect any other architecture, so I think it's properly
> a question for the x86 back-end maintainers.

For the last week or so I've been trying to help ktietz with preparing
the x86_64 backend for Structured Exception Handling and the unwind
tables that win64 uses.

In the process of reading over the MS documentation, it appears that 
the MS compiler is no longer producing the traditional frame pointer.
Indeed, even when they *do* generate a frame pointer, its position in
the frame is lower than usual.  The advantage being that more of the 
local stack frame is addressable via RBP + 8-bit-offset, leading to
smaller code.  I think it would be very nice to be able to make this
change in GCC as well.

In order to do this, I would very much like to wean users off using
the traditional frame pointer and instead rely on the various unwind
libraries.  That MS programmers will now be forced to think in that
direction helps, I think.

Given that if a user files a bug we can always point them to a switch
to re-enable the traditional frame pointer, count me as in favor of the patch.


r~

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

[Paul Pluzhnikov]

I do not have an opinion of whether -O2 should or should not omit frame
pointers, but ...

On Mon, 2 Aug 2010 10:54:59 -0700, H.J. Lu <hjl.tools@gmail.com> wrote:

> We definitely should help our users deal with this change.
> I only propose this for Linux/x86 where backstrace in glibc
> supports unwind table. We can show them how to use
> backstrace in glibc

Unfortunately, backtrace() in glibc is not currently (glibc-2.11) usable
for getting stack traces from places that developers at Google care about;
namely from within malloc and from signal handlers.

If this patch was to go in, we'll just have to add -fno-omit-frame-pointer
for our 32-bit compiles (we already do that for 64-bit ones).

I suspect that above two "use cases" (heap operations and signal handlers)
cover vast majority of users who record stack traces, and the "just use glibc
backtrace" advice will "just not work" for them.

I can provide details, but the executive summary is that in order to allow
backtraces from malloc and from signal handlers, we use libunwind, and
even then we've had to patch glibc in some unpleasant ways, which will
not be acceptable upstream, and which (I suspect) most other users can't
afford to do.  And even after all that patching our solution is not
(yet) robust enough for general use across Google fleet, so we are using
frame-based unwinder for now.

Cheers,
-- 
Paul Pluzhnikov

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

[H.J. Lu]

On Wed, Aug 4, 2010 at 11:51 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
> I do not have an opinion of whether -O2 should or should not omit frame
> pointers, but ...
>
> On Mon, 2 Aug 2010 10:54:59 -0700, H.J. Lu <hjl.tools@gmail.com> wrote:
>
>> We definitely should help our users deal with this change.
>> I only propose this for Linux/x86 where backstrace in glibc
>> supports unwind table. We can show them how to use
>> backstrace in glibc
>
> Unfortunately, backtrace() in glibc is not currently (glibc-2.11) usable
> for getting stack traces from places that developers at Google care about;
> namely from within malloc and from signal handlers.
>
> If this patch was to go in, we'll just have to add -fno-omit-frame-pointer
> for our 32-bit compiles (we already do that for 64-bit ones).
>
> I suspect that above two "use cases" (heap operations and signal handlers)
> cover vast majority of users who record stack traces, and the "just use glibc
> backtrace" advice will "just not work" for them.
>
> I can provide details, but the executive summary is that in order to allow
> backtraces from malloc and from signal handlers, we use libunwind, and
> even then we've had to patch glibc in some unpleasant ways, which will
> not be acceptable upstream, and which (I suspect) most other users can't
> afford to do.  And even after all that patching our solution is not
> (yet) robust enough for general use across Google fleet, so we are using
> frame-based unwinder for now.
>

I am not sure about single handler. For malloc, are you referring to

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724

If it can't be fixed and is very important to you, you have to keep
frame pointer.
It isn't a new problem.


-- 
H.J.

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

[Paul Pluzhnikov]

On Wed, Aug 4, 2010 at 12:13 PM, H.J. Lu <hjl.tools@gmail.com> wrote:

> For malloc, are you referring to
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724

Thanks for the pointer. This is one example, but there are many more.

> It isn't a new problem.

I didn't claim it is.

I am only claiming that glibc backtrace() is currently not a viable solution
for our use cases.

Cheers,
-- 
Paul Pluzhnikov

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

[Xinliang David Li]

Paul just points out the use case in google that unfortunately
requires frame pointer (for now) at the cost of some performance.
There is no objection to the default switching as it is easy to throw
in a build option to override it.

Thanks,

David

On Wed, Aug 4, 2010 at 12:13 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Wed, Aug 4, 2010 at 11:51 AM, Paul Pluzhnikov <ppluzhnikov@google.com> wrote:
>> I do not have an opinion of whether -O2 should or should not omit frame
>> pointers, but ...
>>
>> On Mon, 2 Aug 2010 10:54:59 -0700, H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>>> We definitely should help our users deal with this change.
>>> I only propose this for Linux/x86 where backstrace in glibc
>>> supports unwind table. We can show them how to use
>>> backstrace in glibc
>>
>> Unfortunately, backtrace() in glibc is not currently (glibc-2.11) usable
>> for getting stack traces from places that developers at Google care about;
>> namely from within malloc and from signal handlers.
>>
>> If this patch was to go in, we'll just have to add -fno-omit-frame-pointer
>> for our 32-bit compiles (we already do that for 64-bit ones).
>>
>> I suspect that above two "use cases" (heap operations and signal handlers)
>> cover vast majority of users who record stack traces, and the "just use glibc
>> backtrace" advice will "just not work" for them.
>>
>> I can provide details, but the executive summary is that in order to allow
>> backtraces from malloc and from signal handlers, we use libunwind, and
>> even then we've had to patch glibc in some unpleasant ways, which will
>> not be acceptable upstream, and which (I suspect) most other users can't
>> afford to do.  And even after all that patching our solution is not
>> (yet) robust enough for general use across Google fleet, so we are using
>> frame-based unwinder for now.
>>
>
> I am not sure about single handler. For malloc, are you referring to
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
>
> If it can't be fixed and is very important to you, you have to keep
> frame pointer.
> It isn't a new problem.
>
>
> --
> H.J.
>

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

[Andi Kleen]

"H.J. Lu" <hjl.tools@gmail.com> writes:

> I am not sure about single handler. For malloc, are you referring to

In Linux the kernel provides unwind information for the signal
handler. I just tested it and it works here with a frame pointer
less 32bit executable using gdb.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

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

[David Daney]

On 08/04/2010 01:39 PM, Andi Kleen wrote:
> "H.J. Lu"<hjl.tools@gmail.com>  writes:
>
>> I am not sure about single handler. For malloc, are you referring to
>
> In Linux the kernel provides unwind information for the signal
> handler. I just tested it and it works here with a frame pointer
> less 32bit executable using gdb.

Not that I doubt your claim, but the ability of gdb to unwind signal 
frames is not proof of the existence of kernel unwind information.

gdb can often generate a backtrace (even through signal frames) in the 
absence of any debugging meta-data.

David Daney

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

[Paul Pluzhnikov]

On Wed, Aug 4, 2010 at 1:57 PM, David Daney <ddaney@caviumnetworks.com> wrote:
> On 08/04/2010 01:39 PM, Andi Kleen wrote:
>>
>> "H.J. Lu"<hjl.tools@gmail.com>  writes:
>>
>>> I am not sure about single handler. For malloc, are you referring to
>>
>> In Linux the kernel provides unwind information for the signal
>> handler. I just tested it and it works here with a frame pointer
>> less 32bit executable using gdb.
>
> Not that I doubt your claim, but the ability of gdb to unwind signal frames
> is not proof of the existence of kernel unwind information.

The kernel VDSO page does in fact provide correct unwind info, but that
is completely irrelevant.

The issue here is not that the unwind info is missing; it's that glibc
backtrace() is not async-signal safe (which, given that it calls malloc
shouldn't be a big surprise :-).

Cheers,
-- 
Paul Pluzhnikov

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

[Andi Kleen]

> The issue here is not that the unwind info is missing; it's that glibc
> backtrace() is not async-signal safe (which, given that it calls malloc
> shouldn't be a big surprise :-).

Are you sure? AFAIK it only calls malloc when you register frames,
but not during unwinding itself.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

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

[Paul Pluzhnikov]

On Wed, Aug 4, 2010 at 2:16 PM, Andi Kleen <andi@firstfloor.org> wrote:

>> The issue here is not that the unwind info is missing; it's that glibc
>> backtrace() is not async-signal safe (which, given that it calls malloc
>> shouldn't be a big surprise :-).
>
> Are you sure? AFAIK it only calls malloc when you register frames,
> but not during unwinding itself.

Yes, I double-checked this morning.

The self-deadlock sequence observed with glibc-2.11.1 when calling
backtrace() from inside TCMalloc malloc() was the same as in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724:

backtrace() (first time around) calls dlopen("libgcc_s.so.1"), which
(recursively) calls malloc(), which self-deadlocks.

I am sure this particular problem could be resolved, but I am also sure
there are great many other ways in which backtrace() is not async-signal
safe.

For example, libgcc_s.so.1 _Unwind_Backtrace (which is what glibc
backtrace on x86 dispatches to) calls back into dl_iterate_phdr, which
locks loader lock => kaboom!

-- 
Paul Pluzhnikov

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

[Andi Kleen]

> Yes, I double-checked this morning.

Yes I found it after the post.

> 
> The self-deadlock sequence observed with glibc-2.11.1 when calling
> backtrace() from inside TCMalloc malloc() was the same as in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724:

I think it's only doing  this to avoid the sorting on initialization
time. The easy way to avoid it would be to call init_object() 
for everything early, at the cost of some start up time.

> For example, libgcc_s.so.1 _Unwind_Backtrace (which is what glibc
> backtrace on x86 dispatches to) calls back into dl_iterate_phdr, which
> locks loader lock => kaboom!

Well still -- this stuff should be all fixable and it would seem
odd to leave 4% performance on the table just to avoid fixing a few bugs
in the infrastructure.

People often go to large jumps for much smaller performance improvements.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

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

[David Daney]

On 08/04/2010 03:07 PM, Paul Pluzhnikov wrote:
> On Wed, Aug 4, 2010 at 2:16 PM, Andi Kleen<andi@firstfloor.org>  wrote:
>
>>> The issue here is not that the unwind info is missing; it's that glibc
>>> backtrace() is not async-signal safe (which, given that it calls malloc
>>> shouldn't be a big surprise :-).
>>
>> Are you sure? AFAIK it only calls malloc when you register frames,
>> but not during unwinding itself.
>
> Yes, I double-checked this morning.
>
> The self-deadlock sequence observed with glibc-2.11.1 when calling
> backtrace() from inside TCMalloc malloc() was the same as in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724:
>
> backtrace() (first time around) calls dlopen("libgcc_s.so.1"), which
> (recursively) calls malloc(), which self-deadlocks.
>
> I am sure this particular problem could be resolved, but I am also sure
> there are great many other ways in which backtrace() is not async-signal
> safe.

Most DWARF unwinding data is not async-signal safe (i.e. it is not 
generated with -fasynchronous-unwind-tables).  So using it to generate a 
backtrace from an asynchronous signal handler wouldn't be reliable.

David Daney

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

[Andi Kleen]

> Most DWARF unwinding data is not async-signal safe (i.e. it is not
> generated with -fasynchronous-unwind-tables).  So using it to
> generate a backtrace from an asynchronous signal handler wouldn't be
> reliable.

x86-64 defaults to -fasynchronous-unwind-tables. i386 when this
change was done would need too.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

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

[Richard Henderson]

On 08/04/2010 02:08 PM, Paul Pluzhnikov wrote:
> The issue here is not that the unwind info is missing; it's that glibc
> backtrace() is not async-signal safe (which, given that it calls malloc
> shouldn't be a big surprise :-).

It will only ever call malloc if you are missing PT_GNU_EH_FRAME headers
in your binary.  Which really ought never be true given a modern tool chain.


r~

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

[Andi Kleen]

On Wed, Aug 04, 2010 at 04:11:43PM -0700, Richard Henderson wrote:
> On 08/04/2010 02:08 PM, Paul Pluzhnikov wrote:
> > The issue here is not that the unwind info is missing; it's that glibc
> > backtrace() is not async-signal safe (which, given that it calls malloc
> > shouldn't be a big surprise :-).
> 
> It will only ever call malloc if you are missing PT_GNU_EH_FRAME headers
> in your binary.  Which really ought never be true given a modern tool chain.

It looks like it happened in Paul's case. Maybe we can find a way
to avoid that.  Also there's the loader lock issue Paul pointed out.

Still I'm optimistic that can be all fixed.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.

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

[Andi Kleen]

> Not that I doubt your claim, but the ability of gdb to unwind signal
> frames is not proof of the existence of kernel unwind information.
> 
> gdb can often generate a backtrace (even through signal frames) in
> the absence of any debugging meta-data.

Fair enough. I verified it works using glibc backtrace() too.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

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

[H.J. Lu]

[-- Attachment #1: Type: text/plain, Size: 3479 bytes --]

On Tue, Aug 10, 2010 at 8:52 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sun, Aug 8, 2010 at 7:56 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
>> Hello!
>>
>> 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
>> (cough, cough...).
>>
>> 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
>> 4.6.0.
>>
>> 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).
>>
>> Uros.
>>
>
> I tested this patch on Linux/ia32 and Linux/x86-64. There are no regressions.
>
> I don't have good wording for document:
>
> --
> For 32-bit x86 targets, it is not enabled at @option{-Os} by default.
> This option also can be disabled by default on 32-bit x86 targets by
> configuring GCC with the @option{--enable-frame-pointer} configure
> option.
> --
>
> isn't very accurate.  Any suggestions?
>
> Thanks.
>
>
> --
> H.J.
> ---
> 2010-08-09  H.J. Lu  <hongjiu.lu@intel.com>
>
>        * config.gcc: Handle --enable-frame-pointer.
>
>        * configure.ac: Add --enable-frame-pointer.
>        * configure: Regenerated.
>
>        * config/i386/i386.c (override_options): If not optimize for
>        size, use -fomit-frame-pointer and -fasynchronous-unwind-tables
>        by default for 32-bit code unless configured with
>        --enable-frame-pointer.
>

Here is the updated patch.  Any comments?

Thanks.

-- 
H.J.
--
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.

[-- Attachment #2: gcc-i386-fp-7.patch --]
[-- Type: text/plain, Size: 6724 bytes --]

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.

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 9170fc8..62dd9f6 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -406,6 +406,9 @@ i[34567]86-*-*)
 	if test "x$enable_cld" = xyes; then
 		tm_defines="${tm_defines} USE_IX86_CLD=1"
 	fi
+	if test "x$enable_frame_pointer" = xyes; then
+		tm_defines="${tm_defines} USE_IX86_FRAME_POINTER=1"
+	fi
 	tm_file="vxworks-dummy.h ${tm_file}"
 	;;
 x86_64-*-*)
@@ -413,6 +416,9 @@ x86_64-*-*)
 	if test "x$enable_cld" = xyes; then
 		tm_defines="${tm_defines} USE_IX86_CLD=1"
 	fi
+	if test "x$enable_frame_pointer" = xyes; then
+		tm_defines="${tm_defines} USE_IX86_FRAME_POINTER=1"
+	fi
 	tm_file="vxworks-dummy.h ${tm_file}"
 	;;
 esac
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index c3863ac..a87175c 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2979,32 +2979,6 @@ override_options (bool main_args_p)
   if (TARGET_MACHO && TARGET_64BIT)
     flag_pic = 2;
 
-  /* 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;
-    }
-
   /* Need to check -mtune=generic first.  */
   if (ix86_tune_string)
     {
@@ -3292,6 +3266,38 @@ override_options (bool main_args_p)
   for (i = 0; i < X86_TUNE_LAST; ++i)
     ix86_tune_features[i] = !!(initial_ix86_tune_features[i] & ix86_tune_mask);
 
+#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;
+    }
+
   if (optimize_size)
     ix86_cost = &ix86_size_cost;
   else
@@ -3574,7 +3580,8 @@ override_options (bool main_args_p)
 	       prefix, suffix, sw);
     }
 
-  if ((x86_accumulate_outgoing_args & ix86_tune_mask)
+  if ((!USE_IX86_FRAME_POINTER
+       || (x86_accumulate_outgoing_args & ix86_tune_mask))
       && !(target_flags_explicit & MASK_ACCUMULATE_OUTGOING_ARGS)
       && !optimize_size)
     target_flags |= MASK_ACCUMULATE_OUTGOING_ARGS;
diff --git a/gcc/configure b/gcc/configure
index aa61cd6..ad548fc 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -898,6 +898,7 @@ with_system_libunwind
 enable_secureplt
 enable_leading_mingw64_underscores
 enable_cld
+enable_frame_pointer
 enable_win32_registry
 enable_static
 with_pic
@@ -1597,6 +1598,7 @@ Optional Features:
   --enable-leading-mingw64-underscores
                           Enable leading underscores on 64 bit mingw targets
   --enable-cld            enable -mcld by default for 32bit x86
+  --enable-frame-pointer  enable -fno-omit-frame-pointer by default for 32bit x86
   --disable-win32-registry
                           disable lookup of installation paths in the
                           Registry on Windows hosts
@@ -10708,6 +10710,24 @@ else
 fi
 
 
+# Check whether --enable-frame-pointer was given.
+if test "${enable_frame_pointer+set}" = set; then :
+  enableval=$enable_frame_pointer;
+else
+
+case $target_os in
+linux*)
+  # Enable -fomit-frame-pointer by default for Linux.
+  enable_frame_pointer=no
+  ;;
+*)
+  enable_frame_pointer=yes
+  ;;
+esac
+
+fi
+
+
 # Windows32 Registry support for specifying GCC installation paths.
 # Check whether --enable-win32-registry was given.
 if test "${enable_win32_registry+set}" = set; then :
@@ -17109,7 +17129,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17112 "configure"
+#line 17132 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -17215,7 +17235,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17218 "configure"
+#line 17238 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 24d38aa..dd0b198 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1580,6 +1580,20 @@ AC_ARG_ENABLE(cld,
 [  --enable-cld            enable -mcld by default for 32bit x86], [],
 [enable_cld=no])
 
+AC_ARG_ENABLE(frame-pointer,
+[  --enable-frame-pointer  enable -fno-omit-frame-pointer by default for 32bit x86], [],
+[
+case $target_os in
+linux*)
+  # Enable -fomit-frame-pointer by default for Linux.
+  enable_frame_pointer=no
+  ;;
+*)
+  enable_frame_pointer=yes
+  ;;
+esac
+])
+
 # Windows32 Registry support for specifying GCC installation paths.
 AC_ARG_ENABLE(win32-registry,
 [  --disable-win32-registry

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

[Richard Henderson]

On 08/12/2010 09:19 AM, H.J. Lu wrote:
>>        * config.gcc: Handle --enable-frame-pointer.
>>
>>        * configure.ac: Add --enable-frame-pointer.
>>        * configure: Regenerated.
>>
>>        * config/i386/i386.c (override_options): If not optimize for
>>        size, use -fomit-frame-pointer and -fasynchronous-unwind-tables
>>        by default for 32-bit code unless configured with
>>        --enable-frame-pointer.
>>
> 
> Here is the updated patch.  Any comments?

This patch is ok by me.


r~

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

[Uros Bizjak]

On Thu, Aug 12, 2010 at 6:19 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.

Thanks,
Uros.

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

[H.J. Lu]

On Thu, Aug 12, 2010 at 9:30 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Thu, Aug 12, 2010 at 6:19 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.


-- 
H.J.

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

[Uros Bizjak]

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

Uros.

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

[H.J. Lu]

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.



-- 
H.J.

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

[H.J. Lu]

On Thu, Aug 12, 2010 at 10:03 AM, H.J. Lu <hjl.tools@gmail.com> 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.
>
>

How about this patch?


-- 
H.J.
2010-08-12  Uros Bizjak  <ubizjak@gmail.com>

	* doc/invoke.texi: Update -fomit-frame-pointer for 32-bit Linux
	x86 targets.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index edce703..dbcc212 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5993,6 +5993,11 @@ 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}.

+Starting from GCC version 4.6, the default setting for 32-bit Linux 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

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

[Uros Bizjak]

On Thu, Aug 12, 2010 at 7:06 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.
>>
>>
>
> How about this patch?
>
>
> --
> H.J.
> 2010-08-12  Uros Bizjak  <ubizjak@gmail.com>
>
>        * doc/invoke.texi: Update -fomit-frame-pointer for 32-bit Linux
>        x86 targets.
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index edce703..dbcc212 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -5993,6 +5993,11 @@ 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}.
>
> +Starting from GCC version 4.6, the default setting for 32-bit Linux 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

"... the default setting for 32-bit non-Darwin x86 targets has been
changed to @option{-fomit-frame-pointer} when not optimizing for
size." is what the source says ;)

Uros.

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

[H.J. Lu]

On Thu, Aug 12, 2010 at 10:12 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Thu, Aug 12, 2010 at 7:06 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.
>>>
>>>
>>
>> How about this patch?
>>
>>
>> --
>> H.J.
>> 2010-08-12  Uros Bizjak  <ubizjak@gmail.com>
>>
>>        * doc/invoke.texi: Update -fomit-frame-pointer for 32-bit Linux
>>        x86 targets.
>>
>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
>> index edce703..dbcc212 100644
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -5993,6 +5993,11 @@ 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}.
>>
>> +Starting from GCC version 4.6, the default setting for 32-bit Linux 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
>
> "... the default setting for 32-bit non-Darwin x86 targets has been
> changed to @option{-fomit-frame-pointer} when not optimizing for
> size." is what the source says ;)

As I said, it is complicated. We only changed the default setting
for 32bit Linux x86 targets.  All other x86 targets are unchanged.



-- 
H.J.

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

[Jack Howarth]

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.

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

[Uros Bizjak]

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.

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

[Jack Howarth]

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.

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

[Richard Henderson]

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~

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

[IainS]

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

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

[Richard Henderson]

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~

Re: 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.

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

[Mike Stump]

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.

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

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 304 bytes --]

This change seems to have broken bootstrap with -march=pentium{2,3,-m} on
the 4.6 branch.

http://gcc.gnu.org/PR53728


-- 
gcc-porting
toolchain, wxwidgets            learn a language baby, it's that kind of place
@ gentoo.org                   where low card is hunger and high card is taste

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]