> 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 
   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


Reply via email to