Re: Do not decompress functions sections when copying them to ltrans

> > So would the patch be a lot more difficult if you go down either of > > the routes above? (I think I prefer changing lto_header rather > > than making main_size a bitfield) > > Agreed ;) Hmm, actually it seems things are difficult. All the headers are already compressed by zlib: Contents of

Re: Do not decompress functions sections when copying them to ltrans

On December 12, 2015 7:47:39 PM GMT+01:00, Jan Hubicka wrote: >> > So would the patch be a lot more difficult if you go down either of >> > the routes above? (I think I prefer changing lto_header rather >> > than making main_size a bitfield) >> >> Agreed ;) >Hmm, actually it

Re: Do not decompress functions sections when copying them to ltrans

> > For now I added the information if section is compressed into > > decl_state. I am not thrilled by this but it is only way I found w/o > > wasting 4 bytes per every lto section (because the lto header is not > > really extensible and the stream is assumed to be aligned). > > So this trick

Re: Do not decompress functions sections when copying them to ltrans

On Fri, 11 Dec 2015, Jan Hubicka wrote: > Hi, > this patch makes WPA to copy sections w/o decompressing them. This leads > to a nice /tmp usage for GCC bootstrap (about 70%) and little for Firefox. > In GCC about 5% of the ltrans object file is the global decl section, while > for Firefox it is

Do not decompress functions sections when copying them to ltrans

Hi, this patch makes WPA to copy sections w/o decompressing them. This leads to a nice /tmp usage for GCC bootstrap (about 70%) and little for Firefox. In GCC about 5% of the ltrans object file is the global decl section, while for Firefox it is 85%. I will try to figure out if there is