Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.lang.c
Subject: Re: loop strength reduction (was Another silly question)
Message-ID: <1687@auspex.auspex.com>
Date: 23 May 89 18:01:06 GMT
References: <17812@cup.portal.com> <607@kl-cs.UUCP> <749@mccc.UUCP> <1677@auspex.auspex.com> <17692@mimsy.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 46

>>(I don't know whether there are any compilers that do this or not.)
>
>I fed this through gcc (1.35/vax) using -fstrength-reduce and it
>produced the following equivalent:

...


>(using `-mgnu' one gets a jsobgeq instead of decl+jgeq). ...

What, not a "sobjgeq"?  Perhaps they decided it was unpronounceable.... :-)

...

>...I am surprised that, while it inverts the loop counter, it does not
>use the predecrement addressing mode---I rather expected

...

>Or, alternatively, post-increment:

Oh well.  Silly me; I should have just tried "cc -S -O4" on the Sun-3
here if I wanted to see if any compilers would do the optimizations in
question; when I did so on the "for (i = 0; ...)" loop, I got:

	...
	moveq	#0,d7		# i = 0;
	movl	#_a,a0		# a0 = &a[0];
	moveq	#0,d1
	addl	d1,a0		# a0 += 0;	/* say WHAT? */
	jra	LY00000
LY00001:
	clrl	a0@+		# *a0++ = 0;
	addql	#1,d7		# i++;
LY00000:
	moveq	#33,d1		# if (i < 33)
	cmpl	d1,d7
	jlt	LY00001		# keep looping

	...

which did use post-increment, but generated some superfluous goo (the
"a0 += 0" stuff).  It also didn't bother optimizing the loop test, and
nuking "i" entirely, which it can get away with given that "i" is only
used as an array index in the body of the loop and isn't used at all
after the loop terminates.