From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23742 invoked by alias); 9 May 2003 04:12:09 -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 23735 invoked from network); 9 May 2003 04:12:08 -0000 Received: from unknown (63.201.54.26) by sources.redhat.com with QMTP; 9 May 2003 04:12:08 -0000 Received: (qmail 11884 invoked by uid 10); 9 May 2003 04:12:07 -0000 Received: (qmail 10321 invoked by uid 500); 9 May 2003 04:12:03 -0000 Mail-Followup-To: binutils@sources.redhat.com, hans-peter.nilsson@axis.com, zack@codesourcery.com 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. References: <200305090109.h4919osD009188@ignucius.se.axis.com> <87el38zs39.fsf@egil.codesourcery.com> From: Ian Lance Taylor Date: Fri, 09 May 2003 04:12:00 -0000 In-Reply-To: <87el38zs39.fsf@egil.codesourcery.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00295.txt.bz2 Zack Weinberg writes: > Ian Lance Taylor writes: > > > I take your point, though, which is that though targets other than > > CRIS and m68k emit #APP/#NO_APP around assembler statements, it is > > ineffective and pointless. > > 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? I don't think we can conclude that. There must be some performance benefit from #NO_APP, since in that case gas does not have to call do_scrub_chars(). However, the benefit may be insignificant. We would need to do some timing tests. > Or should gcc be changed to emit #NO_APP at file start? You can't do it blindly. You have to make sure that the gcc output is consistent with what the assembler expects when it does not scrub. The assembler input must not contain any comments, and must not contain any extra whitespace. At least some gcc targets do not meet these conditions. For example, I happen to know that the MIPS backend does not. Ian