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

[Eric Botcazou]

> 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