This is the mail archive of the
mailing list for the GCC project.
Re: Low overhead looping support
- To: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>
- Subject: Re: Low overhead looping support
- From: Jeffrey A Law <law at hurl dot cygnus dot com>
- Date: Fri, 19 Mar 1999 02:11:19 -0700
- cc: Richard Henderson <rth at cygnus dot com>, dje at watson dot ibm dot com, egcs-patches at cygnus dot com
- Reply-To: law at cygnus dot com
In message <email@example.com>you write
> Jeffrey A Law writes:
> > I guess that makes sense. Presumably we add the insn before the jump to
> > loop test for loops where we have not removed that jump. Right Michae
> I'm not sure if I understand what you mean here?
> What we do is replace the conditional jump at the end of the loop with
> the new decrement and branch jump insn.
I _think_ I was referring to loops which are entered via a jump to the exit
test. I didn't see anything which prevented us from trying to use a
low overhead loop for these cases. So we have to make sure to handle it.
Right. But where do we add the insn to initialize the counter register?
> I've written up the entries in md.texi for the
> decrement_and_branch_until_zero and decrement_and_branch_on_count
> insns. However, I'm unhappy with the operation of the latter and have
> come up with another more general scheme.
Well, I'd like to give this code time to settle a little before we revamp it
> For starters d_a_b_o_c is too much of a mouthful and is easy to
> confuse with d_a_b_u_z and so I propose that we have a pair of insns
> doloop_begin and doloop_end to replace init_branch_on_count and
> doloop_begin would have two operands; operand 0 being a const_int
> specifying the number of iterations if this can be computed at
> compile-time or a reg to hold the computed number of iterations at
> run-time; operand 1 being a const_int specifying the number of
> enclosed loops.
> If the number of iterations or enclosed loops cannot be dealt with,
> this pattern would FAIL. Otherwise, a pseudo register would be
> allocated as the loop counter and initialised with the loop iterations
> operand. This register rtx would be stored in a static variable. (I
> envisage that this pattern would also decrement the iteration count by
> one if the looping instruction employed a GE test.)
You can't store it in a static variable if your target allows nested
low overhead loops. Unless I'm missing something.
> The doloop_begin pattern would have a matching doloop_end pattern.
> If the doloop_begin did not FAIL, a label marking the top of the loop
> would be emitted and passed as an operand to the doloop_end pattern
Don't we already have a label which marks the top of the loop?