GCC Bugzilla Bug 19676

AVR Target 20041205 snapshot

gcc version 4.0.0 20041205 (experimental)
 /avrdev/libexec/gcc/avr/4.0.0/cc1.exe -quiet -v looprv.c -quiet -dumpbase
looprv.c -mmcu=atmega169 -auxbase looprv -Os -Wall -version -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -o looprv.s


Loop optimiser fails to reverse simple loop. Example

void testloop5(void)
{
	int i;
	for (i=0;i<100;i++)
	{
		if (!value)
		{
			foo();
		} 
	}
}

generates RTL setting index to 100 then using decrement/branch at end of loop as
expected. However, adding any kind of while/for loop inside outer loop leaves
index unoptimised. For example

void testloop3(void)
{
	int i;
	for (i=0;i<100;i++)
	{
		while (!value)
		{
		foo();
		}
	}
	
}

Here index starts at 0 and increments to 99.

Problem seems to be related to "maybe_multiple" being set in loop scan. However,
since 'i' is never used inside loop there would seem to be no need to check for
multiple setting.

This was tested with AVR target but looks like it will affect any target - I can
provide RTL etc on demand.

Created an attachment (id=8092) [edit]
Testcase c source 

Testloop3() is NOT reversed. Others for reference are.

Created an attachment (id=8093) [edit]
Expanded RTL

Expanded RTL from looprv testcase source

Created an attachment (id=8094) [edit]
Optimised RTL

Final Optimised RTL before asm code generation.

Confirmed, we should be able to do this on the tree level but don't for
testloop2, testloop3, testloop4.

To answer this question:
*  - why is gcc inconsistent in loop reversal bounds????
Because sometimes we do loop reversal on the tree level or the rtl level.  See
above about where we 
don't do it on the tree level.

Do you know if all of these loops were loop reversal for say 3.4.0?

Subject: Re:  Loop optimizer fails to reverse
 simple loop

GCC 3.3.1 did reverse testloop3 but not testloop2() or testloop(4).  So 
4.0 gets 4/5 right an 3.3.1 3/5 right.

Its complicated by other optimisations though on my inner loop code so I 
could not say if testloop3 is a regression. Im trying to get some 
results from 3.4.x

The only issue with inconsistent patterns is that it makes matching 
backend patterns more likely to fail. As we need to catch GE 0 or EQ -1 
after decrement for almost identical code structure. I am not sure if 
this is a real probelm or one that gcc will take care of by alternate 
patter substitutions.


pinskia at gcc dot gnu dot org wrote:

>------- Additional Comments From pinskia at gcc dot gnu dot org  2005-01-28 19:54 -------
>Confirmed, we should be able to do this on the tree level but don't for testloop2, testloop3, testloop4.
>
>To answer this question:
>*  - why is gcc inconsistent in loop reversal bounds????
>Because sometimes we do loop reversal on the tree level or the rtl level.  See above about where we 
>don't do it on the tree level.
>
>Do you know if all of these loops were loop reversal for say 3.4.0?
>
>  
>