Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!edcastle!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.misc Subject: Re: C's sins of commission Message-ID: Date: 16 Oct 90 16:01:25 GMT References: <65697@lanl.gov> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 84 Nntp-Posting-Host: teachc In-reply-to: jlg@lanl.gov's message of 13 Oct 90 20:43:18 GMT On 13 Oct 90 20:43:18 GMT, jlg@lanl.gov (Jim Giles) said: jlg> From article , by jlg> pcg@cs.aber.ac.uk (Piercarlo Grandi): pcg> I most strongly object to call this 'aggressive optimization'. It makes pcg> 'aggressive optimization' look respectable. pcg> Aggressive optimization is where the optimizer rewrites your program in pcg> a supposedly similar form behind your back. [...] jlg> Grandi comes up with this one periodically. I can never pin him down jlg> on a meaning. I am sorry on this -- it is a fairly imprecise concept and I seem not to be able to express it clearly, even if I have given at least several examples. I doubt it can be defined precisely, even if certainly more precisely than pornography... :-) jlg> A compiler is a tool which transforms one representation of a jlg> program (the source) into a semantically equivalent form (the jlg> object code) in another language. If the compiler changes the jlg> semantics of the program during this process, it is _BROKEN_. The jlg> optimizer, as part of the compiler, must obey this same constraint. jlg> If the optimizer changes the semantics of a code, it is _BROKEN_. Yes, as long as the result is correct, an optimizer can do what it wants. But here we are not interested on what a correct optimizer can do; we are interested in what is proper or cost/effective for an optimizer to do. In particular if there is reason to reckon that certain types of optimization are hard to get right, that is the generated code is incorrect with higher probability, they may not be very cost effective. In practice the probability of code being generated incorrectly is indeed an increasing function of optimizer complexity, and of the level of semantic restructing performed by it. So the statement: jlg> An optimizer may be as "aggressive" as the compiler implementor jlg> wants to make it - as long as it doesn't alter the semantics of the jlg> code it's translating. is true but not interesting -- it is a tautology. The interesting question is which transformations, when going from source to target code, are worth doing, performance and reliability wise. Maybe I can find a more understandable way of expressing my thought: I reckon, with some supportive reasoning that I will not repeat here, that the tranformations that do not involve any "horizontal" rewriting of a program's logic are worthwhile. I mean by this tranformations that preserve the structure of the algorithm being translated. If the structure is relatively underspecified (a very high level language) then there is considerable scope for clever implementation strategies. If it is relatively precisely specified (C, other systems implementation languages) then it should be respected. I also regard attempts at reinterpreting low level languages as high level ones, to get around this, as dangerous, or at least inferior to using languages designed at the desired level in the first instance. Aggressive optimization is the idea that restructuring a program *in the course of translation* is both feasible and advantageous, and desirable (cost effective). My contention is that logic restructuring optimizations are more cost effective instead at the source level, whether automatic or manual, and that often automatic is not necessary, manual is sufficient. My main reason for surmising so is that automatic program analysis and rewriting is often far more difficult than code planning and synthesis, and the benefits are not as often competitive with those of more limited and safer alternatives (source analysis and rewriting). More shortly: when -O[2345....] will not raise substantially the probability of getting broken code in most compilers, when it will not result in huge increases in compile time or space, and when it will give substantially better results than hand tuned code, then I will BELIEVE! :-). -- 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