This is the mail archive of the
gcc-regression@gcc.gnu.org
mailing list for the GCC project.
Re: A recent patch increased GCC's memory consumption in some cases!
> > 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.
Well, there is one extra posibility that comes into mind - the script
does two runs, one with --enable-gather-detailed-mem-stats compiler to
get GGC statistics, toehr without with your script to get peak.
Perhaps those are out of sync (ie -fno-tree-ter and such used to be
needed and perhaps I removed it in one of the two copies only)
I can't verify this right now, since I still can't get through RAS.
The script is on britten in /usr/src/SpecTests/scripts.pl-memory
and the runs are done in file called I think mem-run.
Honza
>
> 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