Re: Loop unroll fixes

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

At 10:16 10.10.2001, Mark Mitchell wrote:


>--On Wednesday, October 10, 2001 10:12:38 AM +0200 Wolfgang Bangerth 
><wolfgang.bangerth@iwr.uni-heidelberg.de> wrote:
>
>>
>>>I anticipate those being the last changes for GCC 3.0.2.
>>
>>Not arguing for this just because it happened to bite me, but it might be
>>worth to also look at c++/4512, which is a regression w.r.t. 3.0.1. Franz
>>said he'll look into it.
>
>Thank you for pointing this out.  We need to identify this problem, fix
>it, or remove the patch that is causing it.  Regressions from previous
>3.0 releases are very, very bad.

I already tracked down what's happening and produced a simple fix. 
Bootstrapped and regtested on x86 so far.

The problem here is that if a loop gets unrolled, the uid_luid array 
doesn't get updated. In the testcase the loop getting unrolled is part of 
the loop exit tests of another loop. So when the loop exit insns are 
scanned as in the last change to loop_iterations, we get an abort as soon 
as we hit an insn that was generated by loop unrolling :-(.

Probably the cleanest solution would be to recalculate uid_luid after each 
call to scan_loop. Since this wasn't done so far, I guess this has either 
compile time impacts or would confuse other parts of the loop code.
Fortunately, in this case we can just ignore the insns generated by loop 
unrolling, cause they will contain the same insns than the original loop 
body and it's enough if we test for back edges only in the original ones.

So I suggest the appended patch.

OK to commit?

Franz.

         PR c++/4512
         * unroll.c (loop_iterations): Ignore insns generated by loop 
unrolling.

gcc3-loop-2.patch