Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!ll-xn!mit-eddie!fenchurch.mit.edu!jbs
From: jbs@fenchurch.MIT.EDU (Jeff Siegal)
Newsgroups: comp.arch
Subject: Re: Dhrystone 2.1
Keywords: integer benchmark
Message-ID: <9669@eddie.MIT.EDU>
Date: 13 Jul 88 16:34:04 GMT
References: <517@pcrat.UUCP> <2294@sugar.UUCP> <391@attila.weitek.UUCP> <465@m3.mfci.UUCP>
Sender: uucp@eddie.MIT.EDU
Reply-To: jbs@fenchurch.MIT.EDU (Jeff Siegal)
Organization: MIT EE/CS Computer Facilities, Cambridge, MA
Lines: 22

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 [...]
>it mostly cleans up conceptual errors on the part of the programmer.

I though that Dhrystone 2.1 had been modified to make large amounts of
dead-code elimination impossible by:

	1) Printing out the results at the end
	2) Dividing up the routines into separate
	   source files and specifing that
	   inter-module optimizations not be done.

Given that the results must be printed out at the end, wouldn't the
compiler be doing lots of constant folding rather than dead code
elimination.  I suppose after doing lots of loop unrolling and
removing the resulting invariants from the loops, the loops would turn
out to be empty and could be eliminated, but this doesn't seem very
significant.  Isn't constant folding pretty important to overall
performance?

Jeff Siegal