optimizing compiler design

I wrote
>>The front end should be resolutely non-optimizing.


>Why should this be the case?


Separation of concerns. I like my front end to do the following


scanning -- reporting errors like malformed numbers
parsing -- reporting syntax errors
create syntax tree while parsing
build symbol table
-- do type checking, etc.
generate IL in a walk over syntax tree


You can cram sometimes cram the first 3 into a single pass, or not,
depending on your inclinations. Similarly, it's sometimes possible to
generate IL while parsing, avoiding the overhead of creating the
syntax tree. For research, or home experimentation, I'd build the
syntax tree in any case. Again, it's a matter of separating concerns.
The syntax tree can serve as a nice firewall, allowing you to play
around with different forms of IL without hacking around in the guts
of the parser.


Of course, when you're happy with the front end, you get to leave it
alone and concentrate on the fun stuff. Seriously! Source languages
are often complex ugly things, bulky and hard to manipulate. Your
intermediate can be much simpler, without 11 zillion special cases,
source errors, etc. Makes your optimizer passes much smaller and
simpler than the front end, at least if you're willing to have several
simple optimizer passes versus trying glob many optimizations
together.




>The compiler that my research group
>is writing optimizes a few things (so far) at the high level,


Sure -- there's lots of things you can do at the high level, and
probably lots of things that are more easily done at the high level.
But "high level" doesn't imply "front end." Just generate a
high-level form for your intermediate and work on that. Lots of
people use two different levels of intermediate, doing optimizations
that feel are appropriate for each.


Preston Briggs


--

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