> > I'm trying to get an idea where and why we execute what part of the > pass pipeline (yeah, a two-line patch doing -Og should be possible > after this series ...). This patch removes an odd caller of > execute_pass_list (pass_early_local_passes.pass.sub), named > tree_lowering_passes, which is even undocumented. The two callers > will end up executing distinct parts of the function and the > function performs unnecessary setup. Thus I inlined the > function into its two callers. > > I'm not sure about the history of tree_lowering_passes but > freeing up stuff and compacting blocks is not done consistently > at least ;) The idea is obviously to save memory. > > I'll give this the usual bootstrap & regtest testing. > > Honza, does this look ok? I am going to continue this way > until I can re-architect the toplevel pass structure in a way > that we hand control more to the pass manager. Well, hopefully ;)
Yes, it seems fine. The original idea was to have limited entry points into the pass manager and have one function per every action instead of exposing pass lists as our interface. That is - lowering passes that used to be executed during the parsing to output lower level warnings early enough and compact function body representation to save memory. This was supposed to happen on all functions, even unused, to get more consistency of errors/warnings output here. So program was at one point represented in the lowered functions. This the reason for compactification/dominator tree destruction. The idea was to do this cleanup always when we ended up having program represented in this form at once. That is after lowering, early opt, IPA and assembling This is what tree_lowering_passes used to be. - early optimization passes done during the construction of callgraph lazilly only for reachable functions. At the end of this stage unused stuff was removed and this stage used to happen at the end of each source unit for --combine, so we don't blow up memory completely for --combine GCC bootstrap. - IPA passes This is ipa_passes that sits in cgraphunit.c more or less for historical reasons when non-cgraph enabled frontends would not link anymore if it was elsewhere. (cgraph.c and rest was part of libbackend.a, while cgraphunit.c and tree-inline.c was part only of cgraph enabled backend, that is not f77, and it was having access to tree walking stuff). - rest of optimization executed form final pass over cgraph when it is being output and destroyed. (tree_rest_of_compilation, that probably should also go) My longer term plan was to get cgraphunit out of busyness by moving all the compilation driving logic (i.e. cgraph_optimize) into passes.c and moving most of stuff done out of pass manager into passes. Things got more complicated with introduction of LTO/WHOPR and we moved to unit-at-a-time gimplification that killed original purpose of lowering pases. Honza
