From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6591 invoked by alias); 3 Aug 2010 14:03:43 -0000 Received: (qmail 6503 invoked by uid 22791); 3 Aug 2010 14:03:41 -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,TW_ZJ X-Spam-Check-By: sourceware.org Received: from mail-pv0-f175.google.com (HELO mail-pv0-f175.google.com) (74.125.83.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Aug 2010 14:03:36 +0000 Received: by pvg13 with SMTP id 13so1685773pvg.20 for ; Tue, 03 Aug 2010 07:03:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.199.20 with SMTP id w20mr6850031wff.17.1280844214580; Tue, 03 Aug 2010 07:03:34 -0700 (PDT) Received: by 10.220.182.135 with HTTP; Tue, 3 Aug 2010 07:03:34 -0700 (PDT) In-Reply-To: <4C57E36F.2060703@redhat.com> References: <4C57E36F.2060703@redhat.com> Date: Tue, 03 Aug 2010 14:03: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/msg00186.txt.bz2 On Tue, Aug 3, 2010 at 2:37 AM, Andrew Haley wrote: > On 08/03/2010 10:18 AM, Uros Bizjak wrote: >> On Mon, Aug 2, 2010 at 7:54 PM, H.J. Lu wrote: >> >>>> Here are the updated patch and spread sheet for SPEC CPU 2000/2006 on >>>> Intel Core i7 which shows that -fomit-frame-pointer -fasynchronous-unw= ind-tables >>>> improves performance by up to 12% at -O2 and 8% at -O3. For -Os, it im= proves >>>> performance by up to 20%, but also increases code by up to 36%. >>>> >>>> This patch turns on -fomit-frame-pointer -fasynchronous-unwind-tables = only if >>>> -Os isn't used. >>>> >>>> Tested on Linux/ia32 and Linux/x86-64 with -m32. OK for trunk? >>> >>> Any comments on this patch. =A0Any objections? >> >> IMO, this should be approved by Release Managers, since this decision >> affects distributions and their users. >> >> I have no _technical_ objections to this patch, but I won't approve it >> either due to the reason above. > > It's hard for us to know all the use cases that this patch will break: > there may be many users who unwind the stack by following the call > chain, a technique that has worked for many years. =A0(And was even > sanctioned by the ABI, wasn't it?) =A0We'll know when if push this patch > out and hear the screams. The psABI never guarantees it. If some code still depends on it today, we know how to fix it. > Is this really the right thing to do at this stage in the lifetime of > legacy x86? By the same token, it shouldn't be a big problem. --=20 H.J.