From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1608 invoked by alias); 4 Aug 2010 17:15:12 -0000 Received: (qmail 1596 invoked by uid 22791); 4 Aug 2010 17:15:10 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Aug 2010 17:15:06 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o74HF5bV023729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Aug 2010 13:15:05 -0400 Received: from zebedee.pink (ovpn-113-87.phx2.redhat.com [10.3.113.87]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o74HF3eD027697; Wed, 4 Aug 2010 13:15:04 -0400 Message-ID: <4C59A017.2010304@redhat.com> Date: Wed, 04 Aug 2010 17:15:00 -0000 From: Andrew Haley User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0 MIME-Version: 1.0 To: "H.J. Lu" CC: gcc-patches@gcc.gnu.org Subject: Re: PATCH: Turn on -fomit-frame-pointer by default for 32bit Linux/x86 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00337.txt.bz2 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 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.