Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!think!yale!cmcl2!lanl!lambda!jlg
From: jlg@lambda.UUCP (Jim Giles)
Newsgroups: comp.lang.misc
Subject: Re: Common subexpression optimization
Message-ID: <14228@lambda.UUCP>
Date: 6 Feb 90 20:59:46 GMT
References: <PCG.90Feb5185112@rupert.cs.aber.ac.uk>
Lines: 56

From article <PCG.90Feb5185112@rupert.cs.aber.ac.uk>, by pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi):
> [... constant folding ...]
> This is *not* an optimization. It does not involve second
> guessing the program's semantics. It is just good code
> generation. Like removing redundant code, inlining, reordering
> expression's operands (where allowed by language rules), etc...

Now I understand your problem.  You have a confused notion of the meaning
of "semantics" and "optimization".  Semantics refers to the _meaning_ of
the code.  That is: for a given input, what does the program generate
as output?  Optimization is the use of program transformations to
improve code performance _WITHOUT_CHANGING_SEMANTICS_!  If your optimizer
changes the semantics of your code - it's a broken optimizer.*  Your list
above are _all_ optimizations.  So are strength reduction, common sub-
expression elimination, pipelining, etc..  NONE of these code transformations
involve changes to the program's semantics.  ALL of these techniques fit
into the category of "just good code generation".

Footnote *: The only exception to this is the so-called associative
operators (+, *), which are not, in general, _computationally_
associative.  Languages which allow the compiler to reorder such
operators generally say so _explicitly_ in their documentation and
generally also provide an efficient way to force evaluation order
if it is important.  One could argue that reordering such operators
doesn't change the semantics of the code since such vagueness is part
of the semantics of the operators in the first place.

> [...]
>    It costs compile time, but it's cheaper to use the computer
>    to optimize my code than to do it by hand.
> 
> It encourages less precise coding, and makes the compiler many
> times larger, and these are *very* bad news, and very costly too.

No, coding should _always_ be precise.  Doing common subexpression
elimination by hand is _NOT_ more precise - it is merely more verbose.
Both versions would have _exactly_ the same _meaning_.

> All this to optimize very little pieces of code, which could be
> manually sorted out, and with improvement on their information
> content for both humans and programs that read them.

Manually sorting it out cost programmer time, which _may_ be more
expensive than any possible saving over the life of the program.
Further, be more verbose is not, necessarily, an improvement
in content for the human reader (or, sometimes not even for
the computer - see my next post).  In fact, the kinds of "sorting
out" that you are recommending won't save _any_ time at all on
state-of-the-art compilers.  I would recommend spending your human
resources on types of optimization that compilers _CAN'T_ yet
do automatically.

J. Giles
> Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
> Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
> Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk