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
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
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
This was tested with AVR target but looks like it will affect any target - I can
provide RTL etc on demand.
Created attachment 8092 [details]
Testcase c source
Testloop3() is NOT reversed. Others for reference are.
Created attachment 8093 [details]
Expanded RTL from looprv testcase source
Created attachment 8094 [details]
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
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
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?