Path: utzoo!yunexus!geac!daveb
From: daveb@geac.UUCP (David Collier-Brown)
Newsgroups: comp.lang.c
Subject: Re: optimizers (was Re: volatile)
Summary: What not a source-to-source optimizer?
Message-ID: <2554@geac.UUCP>
Date: 10 Apr 88 20:16:32 GMT
Article-I.D.: geac.2554
Posted: Sun Apr 10 16:16:32 1988
References: <12578@brl-adm.ARPA> <1988Mar25.172355.348@utzoo.uucp> <18686@think.UUCP> <4217@ihlpf.ATT.COM> <10914@mimsy.UUCP> <150@ghostwheel.UUCP>
Reply-To: daveb@geac.UUCP (David Collier-Brown)
Organization: The G. Yac New Products Department
Lines: 19

In article <150@ghostwheel.UUCP> ned@ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) writes:
|  ...  Just because a compiler
| can be made smart enough to move a loop invariant out of a loop does not
| mean that it is a good idea.  It makes more sense to just provide the
| programmer with a warning.  If the code is incorrect, the programmer
| learns something valuable...

  Hmmn.  I suspect that a source-to-source optimizer might be
worthwhile, expecially one which would annotate the source with
some of its assumptions while doing so.
  It probably need not be written to be time- or space-efficent: I'd
take one written in prolong (oops! prolog).

 --dave
-- 
 David Collier-Brown.                 {mnetor yunexus utgpu}!geac!daveb
 Geac Computers International Inc.,   |  Computer Science loses its
 350 Steelcase Road,Markham, Ontario, |  memory (if not its mind) 
 CANADA, L3R 1B3 (416) 475-0525 x3279 |  every 6 months.