Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!dog.ee.lbl.gov!elf.ee.lbl.gov!torek
From: torek@elf.ee.lbl.gov (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: micro-optimizing loops (was Help with casts)
Keywords: pointless, inane :-)
Message-ID: <10450@dog.ee.lbl.gov>
Date: 1 Mar 91 04:40:48 GMT
References: <1991Feb21.040145.8678@cec1.wustl.edu> <409@ceco.ceco.com> <339@smds.UUCP> <414@ceco.ceco.com> <10191@dog.ee.lbl.gov> <14522@ganymede.inmos.co.uk>
Reply-To: torek@elf.ee.lbl.gov (Chris Torek)
Organization: Lawrence Berkeley Laboratory, Berkeley
Lines: 43
X-Local-Date: Thu, 28 Feb 91 20:40:48 PST

>In article <10191@dog.ee.lbl.gov> I wrote:
>>Of course, the best optimization for:
>>	for (i = 1; i < 100; i++)
>>		x += i;
>>is:
>>	x += 4950;

In article <14522@ganymede.inmos.co.uk> conor@inmos.co.uk (Conor O'Neill)
writes:
>No.
>Try
>        { x += 4950; i = 100; }

I was assuming (perhaps unwisely) that everyone understood that the
variable `i' was `dead' after the loop.  The alternative `optimizations'
under discussion were

	for (i = 100; --i > 0;)
		x += i;

and

	for (i = 99; i; i--)
		x += i;

both of which leave i==0.  For these to be suitable `optimizations' for
the original (count-from-1-to-99) loop, the final value of `i' would
have to be irrelevant.  (Actually, it is conceivable that the final
value of `i' might have to be exactly 0 or exactly 100; in real code,
as opposed to pedagogic examples, one should check.)

(You might also note that article <10191@dog.ee.lbl.gov> touched lightly
on compiler transformations that changed the final value of `i' in a
count-down loop from 0 to -1.  I *did* consider it....)

(Richard O'Keefe also pointed out some of the dangers in transforming
code sequences.  One must always be careful of semantics.  The final
value of `i' is such a semantic, and Conor O'Neill is right to be wary
of anything that alters it.  In this particular example, however, the
final value should be considered irrelevant.)
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab EE div (+1 415 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov