Re: optimization/8599: [3.2 regression] loop unroll bug with -march=k6-3

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

On Sunday 01 December 2002 22:41, Eric Botcazou wrote:
> > 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 ?

Yes, this very much sounds like what I saw on PPC, the loop was terminated 
with CNT being 9 instead of 5 IIRC.

> 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 ?

Hmm, no. But I just checked the installed compiler (which has the regression 
causing patch reverted) vs. stage1/cc1 of the running bootstrap. That shows 
that the branch+rth's patch would cause the code quality regression on PPC 
that Dale mentioned. That leaves us with 2 options:

1. revert the regression-causing patch on the branch and apply Richards patch 
only instead (if you can confirm that's enough to fix the K6 bug)
2. apply Richard's and Dale's patch on the branch

Currently I'm leaning towards #2 as we are still very early in the 3.2.2 
phase.

To further complicate things, I've just noticed that Richard committed another 
loop related patch the same day:

2002-07-21  Richard Henderson  <rth@redhat.com>

        * unroll.c (find_splittable_givs): Do not split DEST_ADDR givs
        that are not unrolled completely.

and more a few days later:

2002-07-29  Richard Henderson  <rth@redhat.com>

        * unroll.c (verify_addresses): Remove.
        (find_splittable_givs): Never split DEST_ADDR givs.

I'll check if there are related discussions in the lists whether these patches 
are related at all.

Franz.