Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!oliveb!Ozona!chase From: chase@Ozona.orc.olivetti.com (David Chase) Newsgroups: comp.arch Subject: Re: Dhrystone 2.1 (really optimization) Keywords: integer benchmark Message-ID: <25384@oliveb.olivetti.com> Date: 13 Jul 88 20:42:44 GMT References: <517@pcrat.UUCP> <2294@sugar.UUCP> <391@attila.weitek.UUCP> <465@m3.mfci.UUCP> Sender: news@oliveb.olivetti.com Reply-To: chase@Ozona.UUCP (David Chase) Organization: Olivetti Research Center, Menlo Park, CA Lines: 31 In article <465@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes: >I don't understand why you think "a very good optimizing compiler >will eliminate all the code in Dhrystone". 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. The only possible contradiction that I have seen to my "that's dead wrong" is a paper by some people from HP in last month's Programming Language Design and Implementation Conference (proceedings recently appeared in SIGPLAN notices; they've got sort of a dark blue-green cover). There they talk about maintaining data flow information as transformations are applied to the program--one could conceivably also clean up dead code as it is created in such a system (it appears that they do, to some extent). Nevertheless, inlining and macros will both generate dead code without any conceptual errors on the part of the programmer. David Chase Olivetti Research Center, Menlo Park, CA