Re: Low overhead looping support

[Jeffrey A Law <law at hurl dot cygnus dot com>]

  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