From: Andrew Haley <aph@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Jan Hubicka <hubicka@ucw.cz>,
Mark Mitchell <mark@codesourcery.com>,
gcc-patches@gcc.gnu.org
Subject: Re: PATCH: Turn on -fomit-frame-pointer by default for 32bit Linux/x86
Date: Wed, 04 Aug 2010 16:23:00 -0000 [thread overview]
Message-ID: <4C5993C5.7060606@redhat.com> (raw)
In-Reply-To: <AANLkTi=7z0iDi8dXbNeqaMMLBGqdvadh8U0x=iVkEADX@mail.gmail.com>
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?
>
next prev parent reply other threads:[~2010-08-04 16:23 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 [this message]
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
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=4C5993C5.7060606@redhat.com \
--to=aph@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hjl.tools@gmail.com \
--cc=hubicka@ucw.cz \
--cc=mark@codesourcery.com \
/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).