This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Stabilization on the ARM: an unrolling bug


Jeffrey A Law writes:
 >   > What is wrong with just counting the number of uses of the label at the
 >   > loop top?  Even if we have multiple labels at the loop top, I've yet to
 >   > find a testcase where this approach doesn't work.
 > 
 > Something like this in C code
 > 
 >   if (blah)
 >     foo();
 >   else
 >     bar ();
 > 
 >   for (i = 0; i < 10; i++)
 >     whatever
 > 
 > Either the if or the else clause will have to have a jump to the top of the
 > loop.  Thus the # of references for the loop's entry label will be
 > 1.  Your patch would prevent us from unrolling such a loop when
 > clearly we could.

But in a loop such as this cannot happen since the only way we ever
get to the label at the loop top is from a jump as part of the loop
termination test.

On entry to the loop we have a block of initialisation instructions,
e.g, i = 0 (OK, this may be nothing), followed by the loop termination
test instructions or a jump to these instructions following the loop
body.  Thus we always have instructions before the loop top label.

Even with a do-while loop where don't have any initialisation or
condition testing before we enter the loop, we still emit an
additional label after the INSN_NOTE_LOOP_BEG to mark the loop top.
The if or then clause in you example would jump to label before this
note.

I hope this makes sense.

Michael.







Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]