🚀 go-pugleaf

On 5 Nov 90 22:15:54 GMT, jlg@lanl.gov (Jim Giles) said:

jlg> From article <PCG.90Nov2231021@athene.cs.aber.ac.uk>, by
jlg> pcg@cs.aber.ac.uk (Piercarlo Grandi):

pcg> [...]  Now, the interesting question is how much of a liability in
pcg> terms of reduced confidence is aggressive optimization.  Reasoning
pcg> shows that in way of principle it lowers the reliability of a
pcg> compiler. Show that this is not true, or that if true there are
pcg> compensating advantages, and quantify your argument.

jlg> You are making the assumption that optimization techniques reduce
jlg> the reliability of the compiler.  This is certainly true for
jlg> esoterica.  But, you have also attacked the old standby techniques
jlg> as well.

Whether the technique is well understood or not does not matter that
much -- the *algorithm* may be perfectly safe (even if proving so in the
context of a language whose semantics have not been designed for
transformations is quite hard, even for seemingly simple things like
common subexpression elimination); the hazard comes from the amount of
code needed to implement it. The code may be buggy -- actually *it
will*. More code, more bugs. Do we want 100 thousand lines of compiler
to debug when 10 thousand would do it? No... Naturally not all those 100
thousand are involved in the critical translation business, but the
translation business had better be as streamlined as possible.

More code more bugs, no question about it. It is not an assumption.
Anything that is not related to straight translation means more bugs.

jlg> If I were writing a compiler for _reliability_ alone, I would
jlg> certainly make a complete data flow graph and a complete analysis of
jlg> control flow.  These techniques have been around for decades, are
jlg> stable, and much theoretical work (including correctness proofs) has
jlg> been done:

But these techniques require pretty long and elaborate code. Again, if
we assume (and this is indeed a crazy assumption) that we can find an
algorithm to perform hairy transformations without making mistakes and
then implement the algorithm without bugs, then aggressive optimization
is a no-loss situation (except for compile time and space), and whatever
its benefits on run time and space we shoudl do it. It also wins if we
think the program is a "dusty deck" or the programmer is a "dusty
programmer". But in the latter case programmer's assistants at the
source level seem an even better win.

jlg> in short, they are the most reliable tool after automatic
jlg> parser generators that are available in compiler work.

This is a quite extraordinary statement -- you may be implying that
parsing C's syntax, which has been designed for easy context free LL(1)
parsing, is something as straighforward and reliable as rewriting
sequences of C's statements, which have not been designed for it? (note
that C's *expressions* have actually been designed for rewriting,
instead)

jlg> So, don't pretend your objections are based soley on reliability.

Never claimed this -- the claim is that anything that complicates a
crucial system component like a code generator without demonstrated and
quantified cost/benefit analysis should be treated with caution,
especially if the complication is about doing something that was not
anticipated at design time.

My argument is that such potentially risky business should be a separate
program, that it is the responsbility of the programmer to invoke,
guide, and where the programmer has to check the results. This may look
like too much work, but aggressive optimization is expected to make a
significant difference, like most any optimization, in a few cases, and
these may deserve attention.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk