Low overhead looping support
Jeffrey A Law
law@hurl.cygnus.com
Fri Mar 19 01:11:00 GMT 1999
In message <14033.60087.66148.880720@ongaonga.elec.canterbury.ac.nz>you write
:
> Jeffrey A Law writes:
> > I guess that makes sense. Presumably we add the insn before the jump to
> the
> > loop test for loops where we have not removed that jump. Right Michae
> l?
>
> 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
again.
> 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
> d_a_b_o_c.
>
> 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?
jeff
More information about the Gcc-patches
mailing list