GCC memory consumption increased by recent patch!

[Jan Hubicka]

> Most optimizing compilers are able to do full unit at a time 
> compilation.  Furthermore, those compilers that do link time 
> optimization are clearly doing it.  For the most part the link time 
> optimizers are just the regular optimizer that has been hacked with a 
> front end that reads the special .o information.

Yes, what I am actually worrying about is the link time optimization.  I
hope that we will eventually got into that busyness too.  For normal
compilation units I see no problem with keeping everyting in memory.

Concerning the original memory report, one thing that is probably
spoiled is that the --enable-gather-memory-stats build compiler actually
keeps on side table of every ggc allocated objet that might explain
higher growth of the overall mmap/sbrk memory compared to ggc memory in
the case you allocate number of tiny objects.  The big jumps in memory
usage actually may come from resizing the grand hashtable mapping ggc
object to the on side structures.  So situation is not that bad as it
seemed at first glance, but after all it turned us into interesting
discussion ;)

I will change tester to build both compilers (one with statistics and
one without) and use the other copy to measure overall memory
consumption.
> 
> >>If this is what I have to do for now, this is what I will do.  I had 
> >>just thought that there was more here.
> >>   
> >>
> >
> >For 4.0 lets don't change basic ordering of the passes - I have very bad
> >experiences with these kind of changes that should just work but usually
> >just break everything.  We should do more experimenting on
> >tree-profiling branch.  Perhaps I can get it working there as an
> >alternative option (-ftwo-pass-ipa) and we can see how much it will pay
> >back?
> >
> > 
> >
> Just to get back to basics.  I started looking at the cgraph code to see 
> how to fix this now for this release.  I have a few questions. 
> 
> There does not appear to be any flag or fields that say who is the 
> master version and who is the clone.
> I saw some code that took the node->decl field and passed it to 
> cgraph_node so as to look it up in the hash table.  Does this mean that 
> the node in the hash table is the master and that the best you can do is 
> do the lookup and see if you are yourself?
> 
> Do you ever have the case where there is no master?  i.e. if all calls 

Actually currently there is not much of notion of master node.  I keep
the clones in linked chain started by cgraph_node (node->decl) (this is
going to change in foreseable future to explicit pointer from each node)
however...

> to the function are inlined, does the master go away?

Yes, when there is no out of line copy, there is no cgraph node
representing the offline copy.  However the way inlining works is to
simply replace the offline copy by inline node when the last non-inlined
use disappears by inlining.

So if you declare the node first within the linked chain as a master,
you must expect it eventually disappear when inlining is perfomred
possibly before inlining of the other nodes happens.

Honza
> 
> Kenny
>