This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: proposal for compilation unil wide alias analyis
- From: Zack Weinberg <zack at codesourcery dot com>
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Jan Hubicka <jh at suse dot cz>, Ken Zadeck <zadeck at naturalbridge dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Stuart Hastings <stuart at apple dot com>, Geoff Keating <geoffk at apple dot com>, Mark Mitchell <mark at codesourcery dot com>, Devang Patel <dpatel at apple dot com>, Daniel Berlin <dberlin at dberlin dot org>, David Edelsohn <dje at watson dot ibm dot com>, Dale Johannesen <dalej at apple dot com>, Ron Price <ronp at apple dot com>
- Date: Sat, 26 Jun 2004 12:36:52 -0700
- Subject: Re: proposal for compilation unil wide alias analyis
- References: <40DB07B2.1090108@naturalbridge.com><20040625220852.GA17010@kam.mff.cuni.cz><1088209471.17853.55.camel@localhost.localdomain>
Diego Novillo <dnovillo@redhat.com> writes:
> What would be Really Cool, though, is to have all the function bodies in
> the call graph already in SSA form.
>
> Now, when exactly is cgraph_analyze called? After we called t_r_o_c on
> each function body? That'd be too late. We want to do this analysis
> before we optimize the first body in the call graph.
I'd like to point out some contrary design tensions here. On the one
hand, we want -O0 to be as fast as possible, which entails doing as
little work as possible.[1] On the other hand, doing a certain amount
of work up front may make the compiler faster overall. The usual
rationale for that theory is that simple optimizations may
substantially reduce the size of the code to be generated, thus
requiring less work - if nowhere else, in final assembly output.
Also, whether or not optimization is enabled, if we are generating a
precompiled header it makes sense to do some upfront work to avoid
duplication of effort across translation units later.
There is also an argument from ease of maintenance, for having just
one pipeline from source to object code - in other words, enabling
optimization only enables more passes, it doesn't switch from a
'stupid' pass to a 'smart' one. In particular, if it makes sense to
rewrite the tree-to-RTL expander such that it expects to be fed SSA
form GIMPLE, then we should always give it SSA form GIMPLE, rather
than keeping around another tree-to-RTL expander that can cope with
non-SSA form or even GENERIC.[2]
And finally, we've just been reminded that the lack of uninitialized-
variable warnings at -O0 is an annoying wart that should go away,
which entails doing *some* kind of data flow analysis at -O0.
Conveniently, this is also the analysis that needs doing in order to
do basic constant propagation and dead-code elimination on SSA form.
Taking that all together, my suggested approach would have the parser
responsible for calling just one entry point, let's call it
cgraph_finalize_function, which does conversion to SSA form GIMPLE and
basic CCP/DCE up front. The body is then saved for later. After
lang_hooks.parse_file returns, compile_file calls
cgraph_finalize_compilation_unit, which does all the rest of the work:
constructing the global CFG, inlining, discarding unused functions and
variables, etc etc. (I'm not a huge fan of either of these procedure
names, but I don't have better ideas.) PCH generation probably
belongs buried inside the parse_file hook since it has to happen
before the global scope is destroyed; but we need a way to tell
compile_file not to call c_f_c_g in that case. Maybe artificially
setting flag_syntax_only will do.
zw
[1] Disclaimer: CodeSourcery is under contract to make -O0 as fast as
possible.
[2] People have also made noises about being able to do better
register allocation on SSA form, but I am not holding my breath for
that, having seen what happened to the last few attempts to improve
the register allocator.