This is the mail archive of the gcc@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: BCT optimization



  In message <13842.42108.769314.577897@ongaonga.elec.canterbury.ac.nz>you write:
  > That's the first thing I got rid of.  I suggested to David that we
  > emit a pattern at the start of a BCT loop, tentatively named
  > init_branch_on_count, that sets up the loop count (and possibly emits
  > the looping instruction for targets that have such an instruction at
  > the top of a loop).  The operands for this pattern would include a
  > label marking the start of the loop; a label marking the end of the
  > loop; an iteration count; and possibly a loop depth count (for
  > architectures that support nested zero overhead looping constructs,
  > e.g, the ADI SHARC).
I don't see the need to emit special patterns either.  Make it look like
canonical rtl.

ie, initialize a pseudo before the loop in the normal way to hold the loop
counter.  Then at the end of the loop emit a pattern which decrements the
pseudo and conditionally branches back to the start of the loop.

In addition to being much cleaner, it would allow targets where the count
register is actually a general register to use this optimization (and yes,
such targets exist).


For targets that need to do something weird like set a magic register to the
label which starts the loop, we should do that late in the backend (if you
do it early you're going to pessimize some opts which depend on flow info).
Maybe in machdep_reorg.


  > At the end of the loop we emit another named pattern
  > decrement_and_branch_on_count.  Now this pattern needs to be tightly
  > coupled with init_branch_on_count since it needs to know what register
  > has been assigned the iteration count, for example.  The more I think
  > about this, the best way appears to be using static variables in the
  > backend, in a similar manner to compare and jump patterns.
No.  Look at how check_dbra_loop does this -- much of what it does is similar,
except it's trying to modify an existing basic induction variable.  We're
actually creating a new basic induction variable.

jeff


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