This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Stabilization on the ARM: an unrolling bug
- To: law at cygnus dot com
- Subject: Re: Stabilization on the ARM: an unrolling bug
- From: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>
- Date: Wed, 13 Jan 1999 23:21:01 +1300 (NZDT)
- Cc: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>, richard dot earnshaw at arm dot com, egcs-patches at cygnus dot com
- References: <"13980.20503.92336.582965"@ongaonga.elec.canterbury.ac.nz><27249.916215154@hurl.cygnus.com>
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.