From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 584 invoked by alias); 9 May 2003 04:38:18 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 577 invoked from network); 9 May 2003 04:38:17 -0000 Received: from unknown (HELO mta02ps.bigpond.com) (144.135.25.134) by sources.redhat.com with SMTP; 9 May 2003 04:38:17 -0000 Received: from bubble.local ([144.135.25.69]) by mta02ps.bigpond.com (Netscape Messaging Server 4.15 mta02ps Jul 16 2002 22:47:55) with SMTP id HELRJQ00.AEZ for ; Fri, 9 May 2003 14:38:14 +1000 Received: from CPE-144-136-188-60.sa.bigpond.net.au ([144.136.188.60]) by psmam01bpa.bigpond.com(MAM V3.3.2 71/1414102); 09 May 2003 14:38:14 Received: (qmail 17211 invoked by uid 179); 9 May 2003 04:38:14 -0000 Date: Fri, 09 May 2003 04:38:00 -0000 From: Alan Modra To: Zack Weinberg Cc: binutils@sources.redhat.com, hans-peter.nilsson@axis.com Subject: Re: [RFA:] Fix bug with #APP/#NO_APP when using macros. Message-ID: <20030509043813.GB2166@bubble.sa.bigpond.net.au> Mail-Followup-To: Zack Weinberg , binutils@sources.redhat.com, hans-peter.nilsson@axis.com References: <200305090109.h4919osD009188@ignucius.se.axis.com> <87el38zs39.fsf@egil.codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87el38zs39.fsf@egil.codesourcery.com> User-Agent: Mutt/1.4i X-SW-Source: 2003-05/txt/msg00296.txt.bz2 On Thu, May 08, 2003 at 09:01:14PM -0700, Zack Weinberg wrote: > And since no one has noticed this up to now, does that mean that there > is no real performance benefit to be had from #NO_APP, and we can blow > away all the code that emits it from gcc? Or should gcc be changed to > emit #NO_APP at file start? I just ran a current assembler (without HPAs latest patch) on a powerpc-linux insn-attrtab.s which happens to be well over 6M in size. Without #NO_APP (I used #NO-APP :)) real 0m2.450s user 0m2.370s sys 0m0.090s With #NO_APP real 0m1.917s user 0m1.850s sys 0m0.060s To put these numbers into context, gcc -g took nearly 20 seconds to produce the .s file. ie. the assembly time improvement gained by adding #NO_APP represents about 2.6% of the total time to produce the object file. For a -g -O2 compile the improvement was only 0.86%. -- Alan Modra IBM OzLabs - Linux Technology Centre