From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15578 invoked by alias); 4 Aug 2010 18:12:00 -0000 Received: (qmail 15568 invoked by uid 22791); 4 Aug 2010 18:11:59 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 Aug 2010 18:11:55 +0000 Received: (qmail 21295 invoked from network); 4 Aug 2010 18:11:53 -0000 Received: from unknown (HELO ?192.168.0.105?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 4 Aug 2010 18:11:53 -0000 Message-ID: <4C59AD68.1040704@codesourcery.com> Date: Wed, 04 Aug 2010 18:12:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andi Kleen CC: Andrew Haley , "H.J. Lu" , Jan Hubicka , 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> <877hk6e0wd.fsf@basil.nowhere.org> <4C59A7A7.3070300@redhat.com> <20100804180515.GF13161@basil.fritz.box> In-Reply-To: <20100804180515.GF13161@basil.fritz.box> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00349.txt.bz2 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