Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!ANL-MCS.ARPA!boyle
From: boyle@ANL-MCS.ARPA.UUCP
Newsgroups: mod.computers.pyramid
Subject: Re: problem with the interpretation of certain constants
Message-ID: <8703121529.AA28291@anl-mcs.ARPA>
Date: Thu, 12-Mar-87 10:29:22 EST
Article-I.D.: anl-mcs.8703121529.AA28291
Posted: Thu Mar 12 10:29:22 1987
Date-Received: Fri, 13-Mar-87 06:31:46 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 25
Approved: info-pyramid@mimsy.umd.edu

This is an interesting bug for me.  It appears to be a classic example
of scheduling the optimization (of removing multiplication by 1.0) too 
late in the derivation of the object program, after multiplications by 
1.0 have been converted to a form is which they are no longer easily
identifiable.  

This seems to be a general property of optimizations--"to everything 
there is a season".  They cannot be done too soon, because the
opportunity to apply them may not exist, and they should not be done
too late, because they may be much harder to detect than when done at
the best time, or (as in this case), other cases that shouldn't be
optimized may have been commoned with them.

I would suggest doing this optimization near the source code level.
Doing it at the object code level is likely to leave behind a lot to
clean up--nonoptimal register allocation, etc.  Consider the results
for the expression (a*1.0 - b*c), for example; after the
multiplication by 1.0 is removed, a register (unneed on some machine
architectures) might still be used to hold a.

I discuss this point briefly in a paper "Program Reusability through
Program Transformation" (hey, what can I say?) in the Sept. 84 IEEE
Transactions on Software Engineering.

		Jim Boyle