From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5138 invoked by alias); 4 Aug 2010 17:20:33 -0000 Received: (qmail 5125 invoked by uid 22791); 4 Aug 2010 17:20:31 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mail-vw0-f47.google.com (HELO mail-vw0-f47.google.com) (209.85.212.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Aug 2010 17:20:22 +0000 Received: by vws13 with SMTP id 13so4523579vws.20 for ; Wed, 04 Aug 2010 10:20:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.72 with SMTP id w8mr6374901vch.209.1280942420304; Wed, 04 Aug 2010 10:20:20 -0700 (PDT) Received: by 10.220.182.135 with HTTP; Wed, 4 Aug 2010 10:20:20 -0700 (PDT) In-Reply-To: <4C59A017.2010304@redhat.com> References: <4C5823A1.3040407@codesourcery.com> <4C584DFC.8070907@codesourcery.com> <4C5850CD.5000401@redhat.com> <4C58586F.9080205@codesourcery.com> <20100804145954.GD23733@atrey.karlin.mff.cuni.cz> <4C5993C5.7060606@redhat.com> <4C599DC3.5030307@redhat.com> <4C599EBC.2000400@redhat.com> <4C59A017.2010304@redhat.com> Date: Wed, 04 Aug 2010 17:20:00 -0000 Message-ID: Subject: Re: PATCH: Turn on -fomit-frame-pointer by default for 32bit Linux/x86 From: "H.J. Lu" To: Andrew Haley Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-08/txt/msg00338.txt.bz2 On Wed, Aug 4, 2010 at 10:15 AM, Andrew Haley wrote: > On 08/04/2010 06:12 PM, H.J. Lu wrote: >> On Wed, Aug 4, 2010 at 10:09 AM, Andrew Haley wrote: >>> On 08/04/2010 06:07 PM, H.J. Lu wrote: >>>> On Wed, 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 wrote: >>>>>>>> >>>>>>>> I went through the defualt changing discussion at a time we was in= troducing >>>>>>>> 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. =A0This is the case of oprofi= le >>>>>>>> and some of garbage collector implementations. >>>>>>> >>>>>>> Can we find if oprofile works with -fomit-frame-pointer on 32bit Li= nux/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. =A0I'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." =A0But 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-pointe= r. 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. --=20 H.J.