From: Chris Lattner <clattner@apple.com>
To: Andrew Haley <aph@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: PATCH: Turn on -fomit-frame-pointer by default for 32bit Linux/x86
Date: Wed, 04 Aug 2010 17:08:00 -0000 [thread overview]
Message-ID: <4CDCEC25-9035-478C-B9C1-AAA593021E3B@apple.com> (raw)
In-Reply-To: <4C599DC3.5030307@redhat.com>
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
next prev parent reply other threads:[~2010-08-04 17:08 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-26 16:41 H.J. Lu
2010-08-02 17:55 ` H.J. Lu
2010-08-03 9:18 ` Uros Bizjak
2010-08-03 9:38 ` Andrew Haley
2010-08-03 14:03 ` H.J. Lu
2010-08-03 14:18 ` Daniel Jacobowitz
2010-08-03 14:28 ` H.J. Lu
2010-08-03 15:13 ` Daniel Jacobowitz
2010-08-03 15:35 ` H.J. Lu
2010-08-03 14:05 ` H.J. Lu
2010-08-03 14:11 ` Mark Mitchell
2010-08-03 17:12 ` Mark Mitchell
2010-08-03 17:24 ` Andrew Haley
2010-08-03 17:29 ` H.J. Lu
2010-08-03 17:57 ` Mark Mitchell
2010-08-04 13:21 ` Andrew Haley
2010-08-04 14:29 ` Mark Mitchell
2010-08-04 14:44 ` Andrew Haley
2010-08-04 14:48 ` Bernd Schmidt
2010-08-04 15:00 ` Jan Hubicka
2010-08-04 15:54 ` Andrew Haley
2010-08-04 16:08 ` H.J. Lu
2010-08-04 16:23 ` Andrew Haley
2010-08-04 17:05 ` Andrew Haley
2010-08-04 17:06 ` Andrew Haley
2010-08-04 17:08 ` H.J. Lu
2010-08-09 12:07 ` Mark Wielaard
2010-08-04 17:07 ` H.J. Lu
2010-08-04 17:09 ` Andrew Haley
2010-08-04 17:12 ` H.J. Lu
2010-08-04 17:15 ` Andrew Haley
2010-08-04 17:20 ` H.J. Lu
2010-08-04 17:08 ` Chris Lattner [this message]
2010-08-04 17:36 ` Andi Kleen
2010-08-04 17:41 ` H.J. Lu
2010-08-04 17:47 ` Andrew Haley
2010-08-04 17:53 ` H.J. Lu
2010-08-04 18:05 ` Andi Kleen
2010-08-04 18:12 ` Mark Mitchell
2010-08-04 18:18 ` H.J. Lu
2010-08-17 1:47 ` Maciej W. Rozycki
2010-08-03 17:58 ` David Daney
2010-08-03 17:25 ` H.J. Lu
2010-08-03 17:48 ` Mark Mitchell
2010-08-03 18:18 ` Richard Henderson
2010-08-04 18:52 Paul Pluzhnikov
2010-08-04 19:13 ` H.J. Lu
2010-08-04 19:24 ` Paul Pluzhnikov
2010-08-04 19:25 ` Xinliang David Li
2010-08-04 20:39 ` Andi Kleen
2010-08-04 20:57 ` David Daney
2010-08-04 21:09 ` Paul Pluzhnikov
2010-08-04 21:16 ` Andi Kleen
2010-08-04 22:07 ` Paul Pluzhnikov
2010-08-04 22:16 ` Andi Kleen
2010-08-04 22:45 ` David Daney
2010-08-05 7:00 ` Andi Kleen
2010-08-04 23:11 ` Richard Henderson
2010-08-05 7:23 ` Andi Kleen
2010-08-04 21:13 ` Andi Kleen
2010-08-12 16:22 H.J. Lu
2010-08-12 16:28 ` Richard Henderson
2010-08-12 16:35 ` Uros Bizjak
2010-08-12 16:52 ` H.J. Lu
2010-08-12 17:03 ` Uros Bizjak
2010-08-12 17:07 ` H.J. Lu
2010-08-12 17:12 ` H.J. Lu
2010-08-12 17:13 ` Uros Bizjak
2010-08-12 17:20 ` H.J. Lu
2010-08-12 17:26 ` Jack Howarth
2010-08-12 17:39 ` Uros Bizjak
2010-08-12 17:39 ` Jack Howarth
2010-08-12 17:46 ` Richard Henderson
2010-08-12 17:58 ` IainS
2010-08-12 18:22 ` Richard Henderson
2010-08-12 17:50 ` Uros Bizjak
2010-08-12 23:02 ` Mike Stump
2013-01-30 22:24 ` Ryan Hill
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CDCEC25-9035-478C-B9C1-AAA593021E3B@apple.com \
--to=clattner@apple.com \
--cc=aph@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).