revised PATCH: CALL_EXPR representation changes, part 0/9 (table of contents)

[Jan Hubicka]

> Steven Bosscher wrote:
> >On Friday 16 February 2007 09:50, Jan Hubicka wrote:
> >>Hi,
> >>this is report from memory tester, overall it seems to be slight memory
> >>consumption increase. Are there any plans to get the memory back?
> >
> >Sandra said in a mail last week that there is supposed to be a ~2%
> >memory saving (http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00945.html).
> >That is a number that should be visible in your measurements.  Are you
> >and Sandra measuring the same thing?
> 
> I expect that the current mainline version does show a memory use 
> regression. As I mentioned in another e-mail, I have two additional patches 
> from the LTO branch that I need to bring over to clobber some critical 
> cases where temporary lists are being constructed.  I will try to get to 
> that today.  Anyway, my measurements on the LTO branch were made with those 
> two additional patches in place.

Hi,
if the two additional patches will change memory usage, I will get mail
from memory tester.  However there are case where amount of memory after
garbage collecting increase, this is definitly not attributable to
temporary datastructures.  I am particularly puzzled by the memory
referenced at the end of compilation, in the case of PR28071 it is 6%:

comparing PR rtl-optimization/28071 testcase compilation at -O1 level:
  Overall memory allocated via mmap and sbrk increased from 240608k to 246404k, overall 2.41%
  Peak amount of GGC memory allocated before garbage collecting increased from 84342k to 85924k, overall 1.88%
  Peak amount of GGC memory still allocated after garbage collecting increased from 73896k to 74852k, overall 1.29%
  Amount of memory still referenced at the end of compilation increased from 19610k to 20861k, overall 6.38%

Perhaps little analysis would help.  Memory tester now publish stuff on
webpage http://www.suse.de/~gcctest/memory/ and
http://www.suse.de/~gcctest/memory/results (I just noticed I forgot to
link from the main tester page) contains logs.

The logs in question are 
http://www.suse.de/~gcctest/memory/results/200702160035/pr28071-O1.rep
(from today)
http://www.suse.de/~gcctest/memory/results/200702141642/pr28071-O1.rep
(from day before patch was comitted)

At first glance one curious fact is that:
stringpool.c:77 (alloc_node)                              0: 0.0% 0: 0.0%    6875024:34.2%     528848: 1.7%      66106
ggc-common.c:193 (ggc_calloc)                       6470864: 2.8% 5000784: 8.6%    1761064: 8.8%    1068056: 3.4%        516
changed to:
stringpool.c:77 (alloc_node)                              0: 0.0% 0: 0.0%    7893912:37.0%     607224: 1.9%      75903
ggc-common.c:193 (ggc_calloc)                       6733160: 2.9% 5000784: 8.6%    2023176: 9.5%    1068176: 3.4%        517

The ggc_calloc can be probably attributed to the vectors holding call
expressions, but how can it came into increasing memory usage of
stringpool from 6.8MB to 7.8MB?

Honza