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