Re: Writing fast compilers...

[From comp.arch -John]


davidsen@crdos1.crd.ge.com (bill davidsen) writes:


> Optimizing compilers are not going to
>produce as much improvement on well written code as they will on student
>first attempts, because the common subexpressions have be done in
>source, the invariant stuff is out of loops, the loops are unrolled, the
>register type has been used here and there... all by a one pass code
>generator called a programmer.


I'm going to poke a little at this...
IMHO, traditional optimizations (say, up to vectorization) are mostly
useful for cleaning up addressing expressions -- things that arise
when compiling


A(i, j) = A(i-1, j) * B(i, j-1)


It's the sort of thing C programmers can get at using pointer arithmetic, but
most other languages must leave alone. Field accesses are a wonderful source
of constant additions to be folded, pointer accesses offer lots of
opportunity for common subexpression elimination, and array accesses are
always great for strength reduction. If we happen to catch some extra left
in by the programmer... well, that's fine too.


If you do a good job on your basic optimization, and use some care in
instruction selection and register allocation, the compiler makes the sort of
code you'd hope for -- clean and straightforward, nothing fancy.


I remember C. A. R. Hoare writing persuasively for a language in which "a
simple straightforward 'non-pessimising' compiler will produce
straightforward object programs of acceptable efficiency." To an extent, C
and its early compilers accomplish this, but the amount of detail required of
the programmer seems extreme.


Relying on "a one pass code generator called a programmer" is inadequate.
Programmers aren't 1-pass; they go over the code repeatedly, during the
initial creation and, more importantly, during maintanence.


Therefore, I'd advocate writing clean, straightforward code that correctly
expresses the algorithm you've carefully selected and let the compiler worry
about the low level tedium that they were designed to handle.


Then, if the resulting code is inadequate (or worse, incorrect),
push hard on the vendor to improve his compiler.


Preston Briggs
--

Return to the comp.compilers page.
Search the comp.compilers archives again.