From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28421 invoked by alias); 11 Dec 2012 17:15:15 -0000 Received: (qmail 28376 invoked by uid 22791); 11 Dec 2012 17:15:07 -0000 X-SWARE-Spam-Status: No, hits=-5.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 11 Dec 2012 17:15:00 +0000 Received: by mail-we0-f175.google.com with SMTP id z53so1863716wey.20 for ; Tue, 11 Dec 2012 09:14:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=64NRC7QeQna1UJ5jpH/gYYnkJX1ePt++55R9TzqoCWw=; b=Lu6ft45iXZ1YQoVno9/c+RfrLiRbNwQy/sQCeft+N7ucyprZHJvzC/zsHWBGIXC5nI axH3PXOYy9K+wWOlpEYn6hLMegayeMIH5ZIwAWfYumqN+AYuzMLPevaMoVjosATL8NP9 2yRIEBChYEKt5oxf1wqFJrxN8IYIFro4dptVm5mWWX2FgMFmKDn1o/9qtvkGmGsMR4Tx qb8JQ4FQgAUCMMyB1O+8oSA4YGy/ofK0Ma2JDYtEdFVCi2Rlz1z5Z3yR9lrJIEeLbu3t Enzl0nc63/MXf908J1pTYUwvJHHwAxkpesxhxPocjFGRbJu8UFZufPdP90DVIoneGGkN UkNw== MIME-Version: 1.0 Received: by 10.180.102.101 with SMTP id fn5mr17896014wib.19.1355246099238; Tue, 11 Dec 2012 09:14:59 -0800 (PST) Received: by 10.216.190.207 with HTTP; Tue, 11 Dec 2012 09:14:59 -0800 (PST) In-Reply-To: References: <2679866A-C8BE-4F73-B417-C0A8140D6E99@comcast.net> Date: Tue, 11 Dec 2012 17:15:00 -0000 Message-ID: Subject: Re: [PATCH i386]: Enable push/pop in pro/epilogue for modern CPUs From: Xinliang David Li To: Richard Biener Cc: Mike Stump , Uros Bizjak , GCC Patches Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQljGefRn72NLPjNBkMd5NYY7e3iBdB3/TBd4TDz1dZRoZFWuhtUIq+/mkdU0vU3ZcxPD6hGZwDJgteuOokU7efrgJlpLBT5EWsiXtM+u1Z7JcdY1f4gdTWn3qw1FqEAPvN973uo3rcNiz/4e4Oa4y9Z+dh+/ikstoli1Cm29ZJaLmzJxUAxm4QXRq9JtcOHaY/G26ja 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: 2012-12/txt/msg00715.txt.bz2 On Tue, Dec 11, 2012 at 1:49 AM, Richard Biener wrote: > On Mon, Dec 10, 2012 at 10:07 PM, Mike Stump wrot= e: >> On Dec 10, 2012, at 12:42 PM, Xinliang David Li wro= te: >>> I have not measured the CFI size impact -- but conceivably it should >>> be larger -- which is unfortunate. >> >> Code speed and size are preferable to optimizing dwarf size=85 :-) I'd= let dwarf 5 fix it! > > Well, different to debug info, CFI data has to be in memory to make > unwinding work. > These days most Linux distributions enable asyncronous unwind tables so a= ny > size savings due to shorter push/pop epilogue/prologue sequences has to be > offsetted by the increase in CFI data. I'm not sure there is really a > speed difference > between both variants (well, maybe due to better icache footprint of > the push/pop > variant). Yes, for large applications, this can be crucial to performance. > > That said - I'd prefer to have more data on this before making the switch= for > the generic model. What was your original motivation? Just "theory" or = was > it a real case? 1) some of the very large internal apps I measured benefit from this change (in terms of performance) 2) both ICC and LLVM do the same. I have already committed the patch. I will find some time to collect more size data and post it later. thanks, David > > Thanks, > Richard.