This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Re-write LTO type merging again, do tree merging
- From: Andi Kleen <andi at firstfloor dot org>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Richard Biener <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org, Jan Hubicka <jh at suse dot de>, Michael Matz <matz at suse dot de>, Diego Novillo <dnovillo at google dot com>, andi at firstfloor dot org
- Date: Mon, 17 Jun 2013 19:27:06 +0200
- Subject: Re: [PATCH] Re-write LTO type merging again, do tree merging
- References: <alpine dot LNX dot 2 dot 00 dot 1306141240340 dot 6998 at zhemvz dot fhfr dot qr> <20130615102823 dot GD2605 at atrey dot karlin dot mff dot cuni dot cz> <alpine dot LNX dot 2 dot 00 dot 1306171005280 dot 22313 at zhemvz dot fhfr dot qr> <20130617081241 dot GA31875 at kam dot mff dot cuni dot cz>
On Mon, Jun 17, 2013 at 10:12:41AM +0200, Jan Hubicka wrote:
> > > CPU: AMD64 family10, speed 2100 MHz (estimated)
> > > Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 750000
> > > samples % app name symbol name
> > > 45047 11.7420 lto1 inflate_fast
> >
> > It might be worth changing LTO section layout to include a header
> > that specifies whether a section is compressed or not so we can
> > allow mixed compressed/uncompressed sections in the LTRANS files
> > and avoid decompressing the function sections.
>
> Yes, but this profile shows only decl streaming. Functions do not really show
> up in profile. I guess only way to cut this down is to either use LZO that
> is faster at decompression side and/or reduce amount of data we stream to .o
> files.
Or better snappy / snappy-c. It's faster at compression than LZO and
comparable at decompression.
-Andi