From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95333 invoked by alias); 5 Aug 2015 15:34:34 -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 95324 invoked by uid 89); 5 Aug 2015 15:34:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.5 required=5.0 tests=AWL,BAYES_80,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 05 Aug 2015 15:34:32 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 3426D19CF97; Wed, 5 Aug 2015 15:34:31 +0000 (UTC) Received: from [10.3.236.67] (vpn-236-67.phx2.redhat.com [10.3.236.67]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t75FYSvi012674; Wed, 5 Aug 2015 11:34:29 -0400 Message-ID: <1438788868.21752.45.camel@surprise> Subject: Re: [PATCH 4/4] define ASM_OUTPUT_LABEL to the name of a function From: David Malcolm To: Richard Biener Cc: Trevor Saunders , tbsaunde+gcc@tbsaunde.org, GCC Patches Date: Wed, 05 Aug 2015 15:34:00 -0000 In-Reply-To: <1438788499.21752.39.camel@surprise> 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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00295.txt.bz2 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. 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). [...] Dave