Re: A recent patch increased GCC's memory consumption in some cases!

[Jan Hubicka <jh at suse dot cz>]

> On Thu, 18 Jan 2007, Jan Hubicka wrote:
> 
> > > 
> > > comparing PR rtl-optimization/28071 testcase compilation at -O2 level:
> > >   Ovarall memory allocated via mmap and sbrk decreased from 365202k to 192018k, overall -90.19%
> > >   Peak amount of GGC memory allocated before garbage collecting increased from 207227k to 302461k, overall 45.96%
> > >   Peak amount of GGC memory still allocated after garbage collecting decreased from 192563k to 178766k, overall -7.72%
> > >   Amount of produced GGC garbage increased from 355277k to 586684k, overall 65.13%
> > >   Amount of memory still referenced at the end of compilation decreased from 30387k to 27902k, overall -8.91%
> > 
> > This result is somewhat bogus, the memory consumption indeed peaks after
> > 360MB.  Richard, is it possible for your script to miss the real peak
> > somehow? See  http://www.suse.de/~aj/SPEC/amd64/memory/pr28071-O2.rep
> > All the 240MB of memory are produced by schedule2 pass and we GGC it
> > immediately, so I guess the peak happens just for a short time.
> 
> Well, it tracks the peak VM usage - independent on for how long it
> happens.  A more stable (less gc-change error-prone) quantity to
> measure would be for example the sum of all allocations done.  But of
> course changing it will break all history.

We compute sum of all allocations, your script is really meant to
provide real peak.  Problem here is that the real peak is >400MB (i've
just verified it by looking at TOP scores and it is output by GGC {GC
... -> ...) if you look at the link above) and it is all loglinks
produced by scheduler, but 192MB is reported by the script for whatever
reason.

There has been some weird instability in the numbers for a while, so I
really suspect that there is some sort of bug in accounting the memory
usage.

Honza
> 
> Richard.
> 
> > 
> > Anyway, the savings are in general real - we manage to optimize the
> > function before inlining better and produce a lot better resulting
> > assembly.  Originally dominator optimization reorganized stuff in so
> > weird way it wasn't possible to cleanup (I think it is mentioned in the
> > PR trail).
> > 
> > Honza
> 
> --
> Richard Guenther <rguenther@suse.de>
> Novell / SUSE Labs