Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.misc Subject: Re: Aggressive optimization Message-ID: Date: 2 Nov 90 23:10:21 GMT References: <4699@lanl.gov> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 55 In-reply-to: jlg@lanl.gov's message of 1 Nov 90 22:33:35 GMT On 1 Nov 90 22:33:35 GMT, jlg@lanl.gov (Jim Giles) said: jlg> From article , by jlg> pcg@cs.aber.ac.uk (Piercarlo Grandi): pcg> In a way or another this implies that each language implies a virtual pcg> machine. The task of the code generator is to map the virtual machine pcg> onto the real machine as well as it can, which means faithfully pcg> (semantics) and efficiently (pragmatics). jlg> Unfortunately for your argument, there are few languages which have jlg> definitions of this kind. The definition of a language usually jlg> implies a _class_ of virtual machines. Yes, of course a virtual machine may be left unspecified here and there. You are indeed allowed to view such a virtual machine as a possibly infinite class of more precisely defined virtual machines. Nominalism. jlg> The code generator is allowed to map any of these onto the real jlg> hardware. Any optimizer which generates code which faithfully jlg> implements anything within the class of acceptable behaviours is jlg> correct. Again, the problem is not to show that aggressive optimization is desirable if it assumed bug free. Indeed this idea is a red herring: jlg> If an optimizer leaves the class of acceptable behaviours, it is jlg> _broken_. Write or find a compiler, optimizing or not, for a popular language that is not _broken_ according to your definition. Of course you cannot. Now, the interesting question is how much of a liability in terms of reduced confidence is aggressive optimization. Reasoning shows that in way of principle it lowers the reliability of a compiler. Show that this is not true, or that if true there are compensating advantages, and quantify yoru argument. The burden of proof is on proponents of aggressive optimization, becasue they have to overcome the obvious observation that anything that enlarges or complicates a program will tend to decrease its reliability. jlg> You are trying to limit the compiler to code transformations that jlg> _you_ regard as straightforward. In truth, the compiler is only jlg> limited by the language definition. Only in a theoretical world. It is also limited by what is cost effective, in the sense above. The argument here is not that aggressive optimizations are illegal or impossible; it is whether they are the best alternative, when compared to straightforward code generation plus source level rewriting assistants, from an engineering point of view. -- 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