This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: better wpa [1/n]: merge types during read-in


> > Yes, that's very likely.  If we'd get around to re-do the LTO option saving code
> > we might want to forbid -g0 compile and -g link (dropping -g at link
> > time as soon
> > as we see a single module compiled with -g0).  Then we can free some more
> > stuff, at least with -g0 - though I'm not sure -g0 matters in practice.
> 
> Don't know if it matters to care about it terribly much, but definitely default
> mozilla builds are -g0.
> 
> I assume that now we want to be more selective about what to save for -g and also
> try to push more stuff to bypass WPA. I don't see need for all the type merging
> for stuff that is only referred from debug info. It will be fun to get this done
> however. (either by early debug info output that goes to extra section and is
> distributed to ltrans same way as we distribute bodies or by some other means)

But overall 2GB of IL for Mozilla is not that bad.  Ohter compilers consume
easilly more.  However we need to figure out where the other 4GB is going (mmap
pool is obviously just part of it, probably hashtables consume good part of it,
too) and do something about those 10 minutes of hashtable lookups needed to
read and write out data.

Problem is amount of data we produce for ltrans, that is partly because we ship
debug info into units that won't output it.

I guess I should look into perf and try to produce low overhead profile with
backtraces so we know what hashtables are worse than others. Though we probably
won't see there much surprises.

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]