This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][1/n] Cleanup global pass execution flow
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Richard Guenther <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org, Jan Hubicka <jh at suse dot de>
- Date: Thu, 5 Apr 2012 16:51:01 +0200
- Subject: Re: [PATCH][1/n] Cleanup global pass execution flow
- References: <Pine.LNX.4.64.1204051538411.17575@jbgna.fhfr.qr>
>
> 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