Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!think!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!ukc!dcl-cs!aber-cs!rupert!pcg From: pcg@rupert.cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.misc Subject: Re: Common subexpression optimization Message-ID: Date: 5 Feb 90 18:51:12 GMT References: <4561@scolex.sco.COM> <14214@lambda.UUCP> <2217@sunset.MATH.UCLA.EDU> <4466@brazos.Rice.edu> <4467@brazos.Rice.edu> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 65 In-reply-to: preston@titan.rice.edu's message of 2 Feb 90 03:10:34 GMT In article <4467@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes: I'd like a compiler to make code to make the computer do what I want. Unfortunately, it can't read minds, so I have to write a program to give it a hint. Since it's so stupid, I have to be fairly specific about how it's to do things like multiplying matrices. Agreed. We are speaking of *implementation* languages. On the other hand, an optimizing compiling allows me to avoid too much tedium. Let me be stroppy: I'd say "allows me sloppy, opaque coding". Strength reducers are good enough that I don't need to mess with pointer variables. Various forms of redundancy elimination are good enough that I needn't bother about every little common subexpression. Vectorizers are good enough so that I need not manually insert vector primitives. Register allocators are good enough that I need not scatter register declarations about. About the "good enough" I am somewhat skeptical (especially about the register allocators -- but then again, many modern machines have more registers than variables...). Also, most of the time these optimizations are irrelevant. Constant propagation is strong enough so that I can afford to declare some constants in convenient places, without bothering about folding every constant expression by hand. This is *not* an optimization. It does not involve second guessing the program's semantics. It is just good code generation. Like removing redundant code, inlining, reordering expression's operands (where allowed by language rules), etc... And all these optimizations work exceptionally well on the inner loops that consume so much time. Not entirely true. Again, at least some armchair evidence tends to support the idea that hand care does a lot of good. And the inner loops are rare enough you can devote your attention to them. The optimizer is written once, by the compiler writer. I, on the other hand, write many programs and I'm able to take advantage of the optimizer in all my programs. This argument remains true for good code generation, and the machine independent programming it affords. It is even true for SQL query optimizers, most of the time, and they do *very* high level planning and strategies; but not always. Even with SQL (or similar things) you have to do hand optimization in critical cases. It costs compile time, but it's cheaper to use the computer to optimize my code than to do it by hand. It encourages less precise coding, and makes the compiler many times larger, and these are *very* bad news, and very costly too. All this to optimize very little pieces of code, which could be manually sorted out, and with improvement on their information content for both humans and programs that read them. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk