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!

Jan Hubicka wrote:

Jan Hubicka wrote:



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




it sounds like I want to swap lines 2815 and 2817 of cgraphunit.c and see if it works.

=======
cgraph_characterize_statics ();

cgraph_expand_all_functions ();
=======



This will not help you, since once functions are expanded and compiled,
there is nothing to optimize so the analysis will be faster but they
will do nothing.


Does this mean that cgraph_expand_function actually calls the back end to compile the rest of this function? It looks like it just expands the callees into the callers, fixes up the call graph, and then returns.

One possibility might be to make aliasing (cgraph_characterize_statics?)
to happen before cgraph_decide_inlining so you have fewer nodes to work
on in the case the cloning is not going to make your analysis more
precise.



This is wrong, the cloning can (in the grand scheme of things) make my analysis more precise. See below.

This can also make sense in the case we want to make use of the new
information for intraprocedural IPA and function cloning that is done
before inlining (but I know too little your and Razya's code to be sure
that this can help)

You still need to manage way how to clone the datastrcture associated
with nodes within cgraph_clone_node.  In the case you just have couple
of bitmaps that are read only after the analysis representing properties
of function, I guess you can just keep them shared.

Honza


kenny






I disagree. The best case scenario for the analysis that I am trying to perform is to have
the case where foo is already inlined into bar completely and transparently. I.e. when I scan bar, rather than seeing the call to foo, I see the text of foo and when I look at the call graph for bar, I do not see foo, I see the functions that foo called (at least the ones that were not inlined into this copy of bar. )

I would also argue that for any kind if ipa, this is also what you want to do. Remember my plan (which of course was sent to you by private email a few months ago so no one else reading this will remember it). The way that we plan to do the higher levels of optimization are:

1) Look at the entire compilation unit, doing the inlining. 2) Do some ipa analysis over the entire compilation unit.
3) Apply that analysis to each function.
4) do a few simplifying optimizations (constant prop, dead code, ...) on each function.
5) do the ipa again
6) apply the analysis to each function.

Thus, if I view my current analysis as step 2 where in some future compiler I will do repeat the analysis as step 5, this is exactly what I want. Hopefully, the constant propagator will have deleted some of the remaining function calls because of knowledge that I gained by doing the inlining. Thus when I do the analysis the second time in step 5, it is over a new smaller function, so I get better information.

I would also argue that all of the ipa (like the ip constant propagator) will benefit from doing it later rather than earlier for the same reason.

This kind of master plan becomes a big win in an oo language because once you do an inlining you are likely to know something about the type that made the function call.


Kenny

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