Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site mips.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxr!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!glacier!mips!mash
From: mash@mips.UUCP (John Mashey)
Newsgroups: net.arch
Subject: Re: WICAT DRYSTONE results and an observation
Message-ID: <277@mips.UUCP>
Date: Sat, 21-Dec-85 16:20:04 EST
Article-I.D.: mips.277
Posted: Sat Dec 21 16:20:04 1985
Date-Received: Mon, 23-Dec-85 04:46:09 EST
References: <144@wicat.UUCP> <7710001@acf8.UUCP>
Organization: MIPS Computer Systems, Mountain View, CA
Lines: 27

Hedley Rainnie writes:
> People who write 'C' code like that should consider themselves very
> fortunate indeed to have any live dead analysis done on poor code. I
> would hope no person would write redundant code like that, of course a code
> generator might but I think the WICAT claim is marketing hype to push the
> fact of the live dead analysis. It is a good optimisation though.
> Just a poor way of showing its true value.

1) Code generators might, especially really advanced ones that do
some exotic optimizations.

2) More importantly, it does illustrate the care that must be taken in
pure CPU benchmarks to that try to model the usage patterns of real programs.
Benchmarks really ought not have any obviously dead code or dead
variables.  It's very amusing to see an optimizer optimize away most
of  a synthetic program from the back, eliminating varaibles whose values
are unused, then the computations that set those variables, thus discovering
more that are unused.

3) One simple technique provides clear results with most compilers:
Just before loop ends, call a function passing variables (that would be dead)
as arguments; of course, factor this function call into the usage patterns.
-- 
-john mashey
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash
DDD:  	415-960-1200
USPS: 	MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043