Re: [PATCH 4/4] define ASM_OUTPUT_LABEL to the name of a function

[Trevor Saunders <tbsaunde at tbsaunde dot org>]

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 <tbsaunde@tbsaunde.org> wrote:
> > > > On Mon, Jul 27, 2015 at 11:06:58AM +0200, Richard Biener wrote:
> > > >> On Sat, Jul 25, 2015 at 4:37 AM,  <tbsaunde+gcc@tbsaunde.org> wrote:
> > > >> > From: Trevor Saunders <tbsaunde+gcc@tbsaunde.org>
> > > >> >
> > > >> >         * 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
> > > <raw data>
> > > 
> > > Makes it quite unparsable to editors of course ...
> > 
> > A middle-ground might be to do both:
> > 
> > .raw_data number-of-bytes
> > <raw data>
> 
> Sorry, I hit "Send" too early; I meant something like this as a
> middle-ground:
> 
>   .raw_data number-of-bytes
>   <raw data>
> 
>   ; 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
>