This is the mail archive of the gcc-regression@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: GCC memory consumption increased by recent patch!


> However, when is the inlining actually done?  If by the time I scan the 
> instructions, foo is already in bar, then there is no reason to have 
> data associated with the cloned copy of foo.  If the inlined copy of bar 

It is done at the very end of compilation when the function is being
compiled.  The idea is that the global passes of IPA optimizers should
work without actually touching function bodies, so we can do IPA where
the bodies are stored on disk and loaded on demand in the future.

So what you see is matching the actual control flow of program.

> is what I am scanning and if I can figure out this is a clone, we can do 
> better.  Also, I figure out the set of functions to scan by just looking 

Clones are in the linked list starting on the cgraph_node (node->decl)
and linked via node->next_clone pointer (this is however going to change
soon once we support real cloning for intraprocedural constant
propagation Rayza is working on).

> at the list of cgraph nodes.  If I can see the function after inlining, 
> there is no reason to scan these either. 
> 
> Also, do you ever fix up the cgraph?  I.e. if you inline foo into bar, 
> bar does not really call foo any more, it calls the functions that foo 
> called.

Yes, once the inlining is done, the clones are elliminated.  This is
usefull for memory management to, so I can release the function body
once all it's clones are dead.

Honza
> 
> kenny
> 
> 


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