This is the mail archive of the
mailing list for the GCC project.
Re: Loop unroll fixes
- To: gcc at gcc dot gnu dot org
- Subject: Re: Loop unroll fixes
- From: Jim Wilson <wilson at cygnus dot com>
- Date: Thu, 4 Oct 2001 20:46:18 -0700
- Cc: Mark Mitchell <mark at codesourcery dot com>, Bernd Schmidt <bernds at redhat dot com>, Franz dot Sirl-kernel at lauterbach dot com, hzoli at hzoli dot 2y dot net
- Organization: Cygnus Solutions, CA
In article <email@example.com> you write:
>Mark, Bernd, what about this for mainline and 3.0.2? Somehow the patch
>never made it past an half-approved state. I stumbled over this while
>tracking another (unfortunately unrelated, more info later today) loop bug.
This is partly my fault. I was supposed to finish the patch review that
There are three testcases for Zoltan's 3 patches. Two of these testcases
are not regressions. They fail at -O2 -funroll-loops in both gcc-2.95.2 and
gcc-3.0.1. The bugs should be fixed in mainline of course, but I see no
critical need to include them in gcc 3.0.2.
The third one is a regression. It fails at -O2 -funroll-loops in gcc-3.0.1,
but works with the same options in gcc-2.95.2. This testcase is
do_loop(unsigned long c, char *m)
unsigned long i = 0;
m[i] = 0;
} while (++i != c);
This one is fixed by the small doloop.c patch, which happens to be the one
patch that Bernd did review. There is a rather nice review in
I agree with Bernd's analysis. The submitted patch doesn't fix the underlying
problem, but it does have value since it optimizes away unnecessary code, and
this optimization helps workaround the underlying bug for some testcases.
As such, I think it has enough value, and is safe enough, to be included in
gcc-3.0.2. I am willing to approve this patch for mainline and gcc-3.0.2.
This is the patch in
I need to spend more time looking at the other two patches. If we still
want these patches in gcc-3.0.2, then the review will take longer than if
putting them in mainline is OK, since I need to be more careful with patches
PS The testcase from Franz Sirl is a regressison at -O2, and hence is a
more important problem than any of the 3 testcases from Zoltan which all
require -O2 -funroll-loops to trigger. However, the Zoltan patches are
already 3 months old, so I don't want to delay their review any longer.