This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: optimization/8599: [3.2 regression] loop unroll bug with -march=k6-3
- From: Eric Botcazou <ebotcazou at libertysurf dot fr>
- To: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 1 Dec 2002 22:41:00 +0100
- Subject: Re: optimization/8599: [3.2 regression] loop unroll bug with -march=k6-3
- References: <20021128122933.25461.qmail@sources.redhat.com> <200212011519.04833@enzo.bigblue.local> <200212011955.21238@enzo.bigblue.local>
> This one backported fixes the branch regression:
>
> 2002-07-21 Richard Henderson <rth@redhat.com>
>
> * loop.h (LOOP_AUTO_UNROLL): Rename from LOOP_FIRST_PASS.
> * loop.c (strength_reduce): Update.
> * toplev.c (rest_of_compilation): Do unrolling in the first
> loop pass, not the second.
>
> I'm running a branch bootstrap now on powerpc-linux-gnu and i686-linux-gnu.
Thanks for working it out!
Ironically, this patch alone will probably fix PR opt/8599 on the branch (i.e
without my already commited backported patch), because the failure is related
to the tremendously bad code generated for
for (i = 0; i < 4; i++)
array[i] = 0;
on the K6 processor family at -O2 -funroll-loops. Because GCC first
strength-reduces the loop, it forgets the number of iterations and ends up
unrolling it 8 times (!) and generating a runtime calculation of the number
of iterations. Does a similar thing happen for 961213-1.c on PPC ?
Out of curiosity, did you verify that the testcase provided by Dale in the
message: http://gcc.gnu.org/ml/gcc-patches/2002-09/msg01418.html
pass on the branch after the backport ?
--
Eric Botcazou