Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!lpi.liant.com!rcg From: rcg@lpi.liant.com (Rick Gorton) Newsgroups: comp.lang.misc Subject: Re: Definition of "Aggressive optimization" Message-ID: <1990Nov6.183955.394@lpi.liant.com> Date: 6 Nov 90 18:39:55 GMT References: Organization: Language Processors Inc., Framingham MA Lines: 86 Ungk. Me mongo. Mongo write Code Generator. Code Generator for many Language. Me confused. Me no understand big wurd. What "Aggressive" mean? Seriously, I want to know language (and furthermore, what compiler) is being used here that is being used as the basis for some of the discussion going on: barmar> So aggressive optimization refers to optimization that does barmar> things like interprocedural flow analysis? Are loop unrolling, barmar> strength reduction, and common subexpression elimination barmar> aggressive or not? pcg> They are all aggressive. Even substituting a shift for a multiplication pcg> or division by a power of two may be considered aggressive in certain pcg> languages where the properties of the two are not precisely identical. Huh? If the language spec says that shifting is not the same as multiplying for powers of two, then it is not an AGGRESSIVE optimization to convert the multiply into a shift, rather an ERRONEOUS one. And not just at the intermediate language level. barmar> The only optimizers that are independent of the primitive barmar> operators are peephole optimizers. pcg> Yep, yep. Long live peephole optimizers! Ungk. Mongo totally confused. What peepholer you use? Yes, peephole optimizers are usually independent of the intermediate language, but in the case specified (about no shifting instead of multiplying) It is REQUIRED that the peepholer know some things about the language involved, if it doesn't have hooks into the intermediate language or symbol table to get storage characteristics/requirements, etc. How about an example say you? Okay. Here's a simple one: On the 88K, the integer operation: mul r2, r3, 9 (r2 = 9*r3) takes more than 1 cycle. However, the following 1 cycle instruction does exactly the same thing, but by doing a scaled add: lda.d r2, r3[r3] ( r2 = r3 + (r3 shifted 3 times)) Presumably, this is illegal in the language described. A good peepholer is capable of doing all this, and much more. In fact, there are times when peepholers can (and will) monkey with loops, and pull things out of them that don't need to be in them. But none of this can be done if the language specifies that this behavior is incorrect. pcg> I am sick of having to disassemble compiler output to see where the pcg> optimizer has botched it. I'd rather like that the effort put in the pcg> pursuit of code generator level aggressive optimizers were put into pcg> source code level rewrite assistants, and in making compilers more pcg> stable, efficient, and reliable at doing translation, not rewriting. Which brings me back to: "So what language, and what compiler are you using?" Have you reported your problems to the compiler vendor? Have they been responsive? If not, why are you sticking with that vendor? Or even further, "Is the buggy application written in the WRONG language?" Or how about, "Was the language chosen the correct one, but the person developing the buggy part of the code was not familiar with the language?" Or more more descriptively, "Was the person writing COBOL/FORTRAN programs in PASCAL?" pcg> I intended to say that the code that effects the transformation adds to pcg> the size and complexity of the compiler and therefore affects the pcg> compiler's reliability....You have a large amount of hairy code in the pcg> compiler's bowels, and this is baaaad. I maintain that if the compiler is trying to perform optimizations explicitly prohibited by the language, then having code in the compiler to support these illegal optimizations is bad. Having large amounts of difficult code is only bad if you find bugs or limitations in it that require major rewrites. In this case, we are no longer talking about aggressive compilation, rather software [re]design, engineering, and development issues. All optimization is NOT evil. All compilers are NOT worthless. A compiler is a tool which translates source code into object code. Sorry to have to be the bearer of bad news, but compilers CAN have bugs. Just like Operating Systems. So how about some POSITIVE discussions about what kind of features good software productivity tools have/need, instead of this continuous optimization-bashing festival? -- Richard Gorton rcg@lpi.liant.com (508) 626-0006 Language Processors, Inc. Framingham, MA 01760 Hey! This is MY opinion. Opinions have little to do with corporate policy.