Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!oliveb!orc!Ozona!chase
From: chase@Ozona.orc.olivetti.com (David Chase)
Newsgroups: comp.lang.misc
Subject: Re: Common subexpression optimization
Message-ID: <48957@ricerca.UUCP>
Date: 10 Feb 90 01:40:13 GMT
References: <1625@aber-cs.UUCP>
Sender: news@orc.Olivetti.Com
Reply-To: David Chase <chase@orc.olivetti.com>
Organization: Olivetti Research California, Menlo Park, CA
Lines: 40
Summary:
Expires:
Sender:
Followup-To:

In article <1625@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
>If you reckon that your optimizing compiler is less buggy and
>more intelligent than your programmer, all that I say blows up.
>I have to admit that this is usually the case, though. 

Thanks -- that's one point on which lots of this rests.  I think that
one root in our apparent difference of opinion is the culture -- I've
got a background in compiling, and how optimizations Ought To Be Done
(correctly, to start with).  You seem to enjoy programming in C, and
(in my experience, though things appear to be improving lately) (1) C
compilers have bugs (2) the bugs go unfixed (3) C has been defined by
its compilers, so one person's "bug" is another person's "undocumented
feature".  IF there's someone (the vendor, perhaps?) responsible for
repairing the compiler when bugs are found, THEN it is probably more
cost-effective to repair the compiler than to (try to) educate an army
of programmers in the way of "precise coding".  Now, if you live in a
world of perpetually broken and useless optimizers, then C is not such
a bad way to go, but I'd rather repair the compilers.

Note, too, that people have been writing compilers for some time, and
there have actually been improvements in technology.  There's
table-driven instruction selection (not as useful on a RISC, but
there's still those Other Chips out there), and the algorithms for
doing things like (global) constant propagation and loop invariant
code motion are getting cleaner and less ad hoc.  There's reasonable
algorithms for optimal instruction scheduling (Simons and someone
else, POPL 1990) for a reasonable class of machines.  (Note -- latency
and block loads are one thing that will suck a good deal of registers.
"Vectorization" isn't just for vector machines)

The best argument I know against hand-optimizing your code is that
programmers often don't know what runs fast on the machine that
they're compiling to, and they certainly don't know what will run fast
on the machine that their program will run on 5 years from now.  The
people at Ardent spent some time working on analysis to "deoptimize"
those fucked-up little loops that C programmers are so fond of
writing, so that they could vectorize them (Allen and someone, SIGPLAN
PLDI, 1988).

David