public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/10624: unroll-loops can't unroll nested constant loops
@ 2003-05-05 19:16 Zdenek Dvorak
  0 siblings, 0 replies; 2+ messages in thread
From: Zdenek Dvorak @ 2003-05-05 19:16 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

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);
 >                 }
 >         }
 > }


^ permalink raw reply	[flat|nested] 2+ messages in thread

* optimization/10624: unroll-loops can't unroll nested constant loops
@ 2003-05-05  9:36 thome
  0 siblings, 0 replies; 2+ messages in thread
From: thome @ 2003-05-05  9:36 UTC (permalink / raw)
  To: gcc-gnats


>Number:         10624
>Category:       optimization
>Synopsis:       unroll-loops can't unroll nested constant loops
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon May 05 09:36:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     thome@lix.polytechnique.fr
>Release:        gcc-3.2.1
>Organization:
>Environment:
Red Hat Linux 8.0
>Description:
#include <stdio.h>

/*
 * 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
 */
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);
                }
        }
}
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-05-05 19:16 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-05 19:16 optimization/10624: unroll-loops can't unroll nested constant loops Zdenek Dvorak
  -- strict thread matches above, loose matches on Subject: below --
2003-05-05  9:36 thome

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).