Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!ncar!boulder!sunybcs!rutgers!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.lang.misc
Subject: Re: Query re optimising compilers
Message-ID: <6481@aw.sei.cmu.edu>
Date: 2 Aug 88 13:12:51 GMT
References: <561@etive.ed.ac.uk> <5423@ihlpf.ATT.COM> <6376@aw.sei.cmu.edu> <8445@ihlpb.ATT.COM>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu (Robert Firth)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 38

In article <8445@ihlpb.ATT.COM> nevin1@ihlpb.UUCP (55528-Liber,N.J.) writes:
["optimisation" of multiply when one operand is zero]

>  However, this brings up another question:
>is this truly an optimization?  The way I (used to?) think about
>optimization with respect to execution speed is that
>
>	speed of optimized code >= speed of unoptimized code
>
>for *all instantiations* of a given source statement.  Under this definition,
>things like constant folding, common subexpression elimination, etc., can
>all be considered optimizations.

That's a very good point.  I'm inclined to agree, but I think current
practice is against us.  For example, it is considered an optimisation
to take the CSE out of

	if b1() then x := expression();
	if b2() then y := expression();

even though that costs more when both conditions are false.  Likewise,
compilers cheerfully hoist code out of loops that might be obeyed zero
times.  What do others think?  (Note: I'm aware there are also compiler
correctness issues here, but that's not the point)

Incidentally, I found a great example where constant folding is a
pessimisation (it was on the PE3200), and a colleague found another
on the Mips R2000.  It can be faster on some machines to add two
"short" constants than to load a "long" one, eg on PE3200 this

	x := 12
	y := 12+4

is faster than

	x := 12
	y := 16

Computers are strange creatures.