Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!im4u!oakhill!davet
From: davet@oakhill.UUCP
Newsgroups: comp.arch,comp.sys.nsc.32k
Subject: "Unoptimizing" Dhrystone
Message-ID: <864@oakhill.UUCP>
Date: Wed, 15-Apr-87 04:07:04 EST
Article-I.D.: oakhill.864
Posted: Wed Apr 15 04:07:04 1987
Date-Received: Fri, 17-Apr-87 00:02:54 EST
References: <4190@nsc.nsc.com> <951@moscom.UUCP> <2577@intelca.UUCP> <219@homxb.UUCP> <16151@amdcad.AMD.COM>
Reply-To: davet@oakhill.UUCP (Dave Trissel)
Organization: Motorola Inc. Austin, Tx
Lines: 27
Xref: utgpu comp.arch:879 comp.sys.nsc.32k:69

In article <16151@amdcad.AMD.COM> tim@amdcad.UUCP (Tim Olson) writes:

>In article <219@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes:
>>                               ...  Meanwhile, any advice on modifying
>>the Dhrystone for version 1.2 such that a global optimizer won't be
>>able to remove anything will be appreciated.
>
>One easy fix to Dhrystone is to package it as two (or more) separate c
>files which must be compiled separately, then linked together.  This
>will prevent global optimizers from looking at the entire program at one
>whack .....

Note that there is at least one company, Philon, Inc. which claims to have
an optimization pass which runs on the final linked object code which would
defeat the above tactics.  I myself may be working on such an animal in a few
months.

However, I still think it's vital to get the above changes put into
a new version of Dhrystone because current results are becoming less
meaningfull.

My info on Philon comes from Uniforum 1986 Conference Proceedings Pages 125
to 138.  I have no other knowledge of that company, it's products or the
efficacy of their compiler system.

 -- David Trissel  Motorola Semiconductor Inc., Austin, Texas
	       {siesmo,ihnp4}!ut-sally!im4u!oakhill!davet