Loop oddity

[Tom Crispin]

John David Anglin wrote:
> 
> Here is a loop oddity that I noticed.  The loop
> 
>   for (i = 1000000; i; i--) {};
> 
> yields the following assembly code when compiled at -O2 on the PA:
> 
>         ldil L'999424,%r19
>         ldo 576(%r19),%r19
>         ldo -625(%r19),%r19
> L$0109
>         comib,<>,n 0,%r19,L$0109
>         ldo -625(%r19),%r19
> 
> You get similar results on other architectures.  I was mystified by
> the transformation of the decrement from 1 to 625.  Looking
> at the output of the loop pass, I see that it has unrolled the loop:
> 
> Loop from 12 to 26: 2 real insns.
> Continue at insn 18.
> Biv 94: insn 20 const (-1)
> Biv 94: verified
> Biv 94: initialized at insn 11: initial value (1000000)
> Cannot eliminate nonneg biv 94.
> Sorted combine statistics:
> 
> Loop unrolling: 1000000 iterations.
> Unrolling loop 25 times.
> Biv 94 safe to split.
> 
> Loop from 12 to 26: 2 real insns.
> Continue at insn 102.
> Biv 94: insn 103 const (-25)
> Biv 94: verified
> Biv 94: initialized at insn 11: initial value (1000000)
> Cannot eliminate nonneg biv 94.
> Sorted combine statistics:
> 
> Loop unrolling: 40000 iterations.
> Unrolling loop 25 times.
> 
> The documentation states that loops are not unrolled at -O2.
> -fno-unroll-loops has no effect.  Of course, if there is something
> in the body of the loop, this doesn't happen.  I noticed this
> trying to write a little program to check insn timing.  Thus,
> I didn't want the loop transformed.
> 
> Dave
> --
> J. David Anglin                                  dave.anglin@nrc.ca
> National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)


I'm not seeing this effect on x86 ....  


-- 
Tom Crispin
Centaur Technology
512-493-8625
crispin@centtech.com