Path: utzoo!attcan!uunet!mfci!colwell From: colwell@mfci.UUCP (Robert Colwell) Newsgroups: comp.arch Subject: Re: Dhrystone 2.1 (really optimization) Keywords: integer benchmark Message-ID: <467@m3.mfci.UUCP> Date: 17 Jul 88 18:54:10 GMT References: <517@pcrat.UUCP> <2294@sugar.UUCP> <391@attila.weitek.UUCP> <465@m3.mfci.UUCP> <25384@oliveb.olivetti.com> Sender: root@mfci.UUCP Reply-To: colwell@mfci.UUCP (Robert Colwell) Organization: Multiflow Computer Inc., Branford Ct. 06405 Lines: 40 In article <25384@oliveb.olivetti.com> chase@Ozona.UUCP (David Chase) writes: >In article <465@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes: >>The dead-code removal >>phase of the compiler isn't really all that important in terms of >>overall object code performance -- it mostly cleans up conceptual > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>errors on the part of the programmer. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > >That's dead wrong. Every account of dead code elimination that I have >ever seen points out that DCE cleans up after the optimizer. I >suggest that you read (for instance) _Program Flow Analysis_ (eds. >Muchnick and Jones. Prentice-Hall), or _Compilers: Principles, >Techniques, and Tools_ (Aho, Sethi, and Ullman. Addison-Wesley). > >Use of macros and inline-functions is one fruitful source of dead >code. Substitution of constant actual parameters into inlined >subroutines can easily yield dead code. I sit corrected, having been already taken to task by our compiler writers. On the other hand, I notice you didn't take up the central point I was ineptly trying to make, to wit: why should I believe that a compiler which does a decent job of dead-code removal will exhibit this ability to the same extent on Dhrystone as it would on the normal sources, which do not require the compiler to look across procedure call/function invocation boundaries? The "conceptual errors" I was referring to were calls to functions or procedures that didn't return anything and made no changes to global state; it wasn't clear to me (and still isn't) why I should make sure my compiler is really adept at finding and removing these, when the only way they arise is via broken programming (or synthetic benchmarks). Bob Colwell mfci!colwell@uunet.uucp Multiflow Computer 175 N. Main St. Branford, CT 06405 203-488-6090