Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?)

mike@hpfcso.hp.com (Mike McNelly)
Tue, 5 Jun 90 04:31:51 GMT

          From comp.compilers

Related articles
Unsafe Optimizations (WAS: Compiler Design in C How about it?) pardo@cs.washington.edu (1990-06-04)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) larus@spool.cs.wisc.edu (1990-06-04)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) MERRIMAN@ccavax.camb.com (George Merriman -- CCA/NY) (1990-06-05)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) mike@hpfcso.hp.com (1990-06-05)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) pardo@cs.washington.edu (1990-06-05)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) robinson@cs.dal.ca (1990-06-05)
Unsafe Optimizations (WAS: Compiler Design in C How about it?) stewart@sdsu.edu (1990-06-05)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) poser@csli.stanford.edu (1990-06-06)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) larus@primost.cs.wisc.edu (1990-06-07)
Re: Unsafe Optimizations (WAS: Compiler Design in C How about it?) tli@%phakt.usc.edu (1990-06-07)
[4 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: mike@hpfcso.hp.com (Mike McNelly)
References: <1990Jun4.044255.14857@esegue.segue.boston.ma.us>
Date: Tue, 5 Jun 90 04:31:51 GMT
Organization: Hewlett-Packard, Fort Collins, CO, USA
Keywords: optimize, C

Almost all compiler courses and texts I've seen in the past 10 years
have mainly devoted themselves to front end theory. My guesses about
why this is happening are:


1) The theory is neat, self contained, well understood and it
appeals to academia's sense of balance. It's also a subject
that can be covered adequately in one semester. The fact that
it has less practical use for graduates who work in compilers is
secondary. There's always a tendency to answer the easy
questions (that have neat answers) rather than the important
ones.


2) Lots of people take one course in compilers. Hence, lots of
books are written for the first course. Few take a second
course so the market for texts describing the back end is a lot
smaller. Reluctantly I'd have to agree that the first course in
compilers/language theory should discuss automata and some
parsing. People who write compilers, however, don't spend much
time doing this stuff anymore.


3) There's lots of optimization theory around. The trouble is,
theory alone just doesn't do much good. To measurably improve
code you have to know when to optimize and when not to and you
have to consider the intimacies of the particular architecture.
Academics hate to describe particular machines in texts because
a) the audience is too limited, and b) your text becomes dated
as soon as the machine becomes obsolete.


4) The incentive for the development of most early (and
fundamental) optimization theory was to improve FORTRAN.
Academics hate FORTRAN. They also write most of the texts.


5) Optimization theory only discusses the easy cases. When it's
time to discuss the really nasty issues of aliasing, etc.,
there's usually a lot of general statements and maybe even a
little hand waving.


These are only personal views. Treat them as religion only. It really
would be nice, though, if a few of the candidates I interview for jobs
in compiler technology had an adequate exposure to the back end of a
compiler however unclean it may be.


Mike McNelly
mike%hpfcla@hplabs.hp.com
[I agree, the textbooks tend to dwell on the easy parts. When I was teaching
compiler courses ten years ago, my inclination was to tell people to read
about the easy parts in the books because I'd only go over them quickly in
class, and I'd spend more class time on the stuff not well treated in the
texts. For some reason, this approach was not treated with a lot of
enthusiasm. -John]
--


Post a followup to this message

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