From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109450 invoked by alias); 5 Aug 2015 20:23:50 -0000 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 Received: (qmail 109431 invoked by uid 89); 5 Aug 2015 20:23:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.1 required=5.0 tests=AWL,BAYES_99,BAYES_999,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: paperclip.tbsaunde.org Received: from tbsaunde.org (HELO paperclip.tbsaunde.org) (66.228.47.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 05 Aug 2015 20:23:48 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (unknown [66.207.208.102]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id C8901C06A; Wed, 5 Aug 2015 20:23:45 +0000 (UTC) Date: Wed, 05 Aug 2015 20:23:00 -0000 From: Trevor Saunders To: David Malcolm Cc: Richard Biener , tbsaunde+gcc@tbsaunde.org, GCC Patches Subject: Re: [PATCH 4/4] define ASM_OUTPUT_LABEL to the name of a function Message-ID: <20150805202212.GA6847@tsaunders-iceball.corp.tor1.mozilla.com> References: <1437791820-17927-1-git-send-email-tbsaunde+gcc@tbsaunde.org> <1437791820-17927-5-git-send-email-tbsaunde+gcc@tbsaunde.org> <20150805105650.GA27755@tsaunders-iceball.corp.tor1.mozilla.com> <1438788499.21752.39.camel@surprise> <1438788868.21752.45.camel@surprise> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1438788868.21752.45.camel@surprise> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-08/txt/msg00312.txt.bz2 On Wed, Aug 05, 2015 at 11:34:28AM -0400, David Malcolm wrote: > On Wed, 2015-08-05 at 11:28 -0400, David Malcolm wrote: > > On Wed, 2015-08-05 at 13:47 +0200, Richard Biener wrote: > > > On Wed, Aug 5, 2015 at 12:57 PM, Trevor Saunders wrote: > > > > On Mon, Jul 27, 2015 at 11:06:58AM +0200, Richard Biener wrote: > > > >> On Sat, Jul 25, 2015 at 4:37 AM, wrote: > > > >> > From: Trevor Saunders > > > >> > > > > >> > * config/arc/arc.h, config/bfin/bfin.h, config/frv/frv.h, > > > >> > config/ia64/ia64-protos.h, config/ia64/ia64.c, config/ia64/ia64.h, > > > >> > config/lm32/lm32.h, config/mep/mep.h, config/mmix/mmix.h, > > > >> > config/rs6000/rs6000.c, config/rs6000/xcoff.h, config/spu/spu.h, > > > >> > config/visium/visium.h, defaults.h: Define ASM_OUTPUT_LABEL to > > > >> > the name of a function. > > > >> > * output.h (default_output_label): New prototype. > > > >> > * varasm.c (default_output_label): New function. > > > >> > * vmsdbgout.c: Include tm_p.h. > > > >> > * xcoffout.c: Likewise. > > > >> > > > >> Just a general remark - the GCC output machinery is known to be slow, > > > >> adding indirect calls might be not the very best idea without refactoring > > > >> some of it. > > > >> > > > >> Did you do any performance measurements for artificial testcases > > > >> exercising the specific bits you change? > > > > > > > > sorry about the delay, but I finally got a chance to do some perf tests > > > > of the first patch. I took three test cases fold-const.ii, insn-emit.ii > > > > and a random .i from firefox and did 3 trials of the length of 100 > > > > compilations. The only non default flag was -std=gnu++11. > > > > > > > > results before patch hookizing output_ascii > > > > > > > > fold-const.ii > > > > real 3m18.051s > > > > user 2m41.340s > > > > sys 0m36.544s > > > > real 3m18.141s > > > > user 2m42.236s > > > > sys 0m35.740s > > > > real 3m18.297s > > > > user 2m42.316s > > > > sys 0m35.804s > > > > > > > > insn-emit.ii > > > > real 9m58.229s > > > > user 8m26.960s > > > > sys 1m31.224s > > > > real 9m57.857s > > > > user 8m24.616s > > > > sys 1m33.072s > > > > real 9m57.922s > > > > user 8m25.232s > > > > sys 1m32.512s > > > > > > > > mozilla.ii > > > > real 8m5.732s > > > > user 6m44.888s > > > > sys 1m20.764s > > > > real 8m5.404s > > > > user 6m44.468s > > > > sys 1m20.856s > > > > real 7m59.197s > > > > user 6m39.632s > > > > sys 1m19.472s > > > > > > > > after patch > > > > > > > > fold-const.ii > > > > real 3m18.488s > > > > user 2m41.972s > > > > sys 0m36.388s > > > > real 3m18.215s > > > > user 2m41.640s > > > > sys 0m36.432s > > > > real 3m18.368s > > > > user 2m42.492s > > > > sys 0m35.720s > > > > > > > > insn-emit.ii > > > > real 10m4.700s > > > > user 8m32.536s > > > > sys 1m32.120s > > > > real 10m4.241s > > > > user 8m31.456s > > > > sys 1m32.728s > > > > real 10m4.515s > > > > user 8m32.056s > > > > sys 1m32.396s > > > > > > > > mozilla.ii > > > > real 7m58.018s > > > > user 6m38.008s > > > > sys 1m19.924s > > > > real 7m59.269s > > > > user 6m37.736s > > > > sys 1m21.448s > > > > real 7m58.254s > > > > user 6m37.828s > > > > sys 1m20.324s > > > > > > > > So, roughly that looks to me like a range from improving by .5% to > > > > regressing by 1%. I'm not sure what could cause an improvement, so I > > > > kind of wonder how valid these results are. > > > > > > Hmm, indeed. The speedup looks suspicious. > > > > > > > Another question is how one can refactor the output machinary to be > > > > faster. My first thought is to buffer text internally before calling > > > > stdio functions, but that seems like a giant job. > > > > > > stdio functions are already buffering, so I don't know either. > > > > > > But yes, going the libas route would improve things here, or for > > > example enhancing gas to be able to eat target binary data > > > without the need to encode it in printable characters... > > > > > > .raw_data number-of-bytes > > > > > > > > > Makes it quite unparsable to editors of course ... > > > > A middle-ground might be to do both: > > > > .raw_data number-of-bytes > > > > Sorry, I hit "Send" too early; I meant something like this as a > middle-ground: > > .raw_data number-of-bytes > > > ; comment giving the formatted text > > so that cc1 etc are doing the formatting work to make the comment, so > that human readers can see what the raw data is meant to be, but the > assembler doesn't have to do work to parse it. well, having random bytes in the file might still screw up editors, and I'd kind of expect that to be slower over all since gcc still does the formating, and both gcc and as do more IO. > FWIW, I once had a go at hiding asm_out_file behind a class interface, > trying to build up higher-level methods on top of raw text printing. > Maybe that's a viable migration strategy (I didn't finish that patch). I was thinking about trying that, but I couldn't think of a good way to do it incrementally. Trev > > [...] > > Dave >