proposal for compilation unil wide alias analyis
Mark Mitchell
mark@codesourcery.com
Sat Jun 26 20:02:00 GMT 2004
Zack Weinberg wrote:
>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]
>
>
I agree with the ease-of-maintenance argument, but I'm not sure it
should triumph. For speed of -O0 comilation, avoiding going into SSA
form at all seems like it would be a win. In other words, I'd expect
that having the tree-to-RTL expanders take GENERIC -- or even
near-generic with callbacks into the front end to expand non-GENERIC
bits to GENERIC on the fly -- would be a win over forcing everything to
be converted to SSA GIMPLE first. The fewer passes we make over the
tree structure, the better.
The Laffer curve argument (we can remove so much code in the optimizers
so quickly that generating the code will actually be faster) seems to me
like it is one that should be proven experimentally before we commit to it.
(For reference, I've seen compilers that had two completely different
code generators: one for optimized code and one for unoptimized code.
They basically split after front end processing into completely
different bodies of code. The unoptimized code version was very dumb,
but very fast.)
--
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com
More information about the Gcc
mailing list