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 attachment 8092 [details] Testcase c source Testloop3() is NOT reversed. Others for reference are.
Created attachment 8093 [details] Expanded RTL Expanded RTL from looprv testcase source
Created attachment 8094 [details] 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? > > >
Fixed a long time ago in GCC 4.6.0. Everyone except for testloop2 was fixed in GCC 4.5.0 (which was PR 40886 and PR 31238 ). I have not looked into what fixed it in GCC 4.6 though.