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