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