Re: optimization/10624: unroll-loops can't unroll nested constant loops

[Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>]

The following reply was made to PR optimization/10624; it has been noted by GNATS.

From: Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz>
To: thome@lix.polytechnique.fr
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: optimization/10624: unroll-loops can't unroll nested constant loops
Date: Mon, 5 May 2003 21:09:48 +0200

 Hello,
 
 > /*
 >  * GCC is apparently unable to understand that this loop can be unrolled.
 >  *
 >  * That's a pity, as we would really want to avoid jumps (of course,
 >  * replace printf by some more critical code. I've got an example of such
 >  * code where ``manual'' unrolling wins 25%, and I guess that much larger
 >  * gaps can be obtained easily...)
 >  *
 >  * It is not a matter of MAX_UNROLLED_INSNS hitting the bound. The inner
 >  * loop is constant when the outer is expanded, but I guess unroll-loops
 >  * makes 1 pass only.
 >  *
 >  * Would it be prohibitive to handle such cases that might require
 >  * several passes for proper unrolling ?
 >  *
 >  * gcc -O3 -funroll-loops -S unroll_me.c
 >  */
 
 yes it does not. Even in 3.4. It would be doable (we are able to unroll
 non-innermost loops, but we do not do it as it rarely helps), but it
 would require nontrivial amount of work. After all the other issues with
 the loop optimizer are solved, I might look at things like this, but this
 is not going to be true for at least a year.
 
 Zdenek
 
 > void unroll_me()
 > {
 >         const int n = 3;
 >         int i, j;
 > 
 >         for(i=0;i<n;i++) {
 >                 for(j=0;j<i;j++) {
 >                         printf("%d, %d\n",i,j);
 >                 }
 >         }
 > }