BCT optimization

Jeffrey A Law law@cygnus.com
Mon Sep 21 23:45:00 GMT 1998

  In message < 9809220411.AA34884@marc.watson.ibm.com >you write:
  > 	After looking over the BCT optimization code, it looks like it
  > should make much more use of the information calculated in
  > unroll.c:loop_iterations() instead of recalculating the values itself and
  > duplicating most of the code.  Because some of the information is in
  > static variables, I think that the BCT optimization functions should be
  > moved to unroll.c as well.  Does anyone object to this?
I think I was either planning on making those variables global or
having a function to get them.  I think BCT belongs in loop.c since
it has nothing to do with loop unrolling.

One could argue that some of the code in unroll.c should move into
loop.c, and that may be a good thing to do.

  > 	I think that because of the order that loops are processed (inner
  > to outer) and all of the information calculated in loop_iterations(),
  > analyze_loop_iterations() could be removed and the decision to instrument
  > the loop with a BCT instruction decided in insert_bct() itself.  This also
  > would allow the optimization to avoid committing the count register unless
  > it actually was used for the loop (unrolling or other transformations
  > might make the optimization ineffective after the initial analysis thought
  > it profitable and committed the count register).
Yea.  I'd noticed this myself.  I don't remember if I'd started down
the path to delay committing to BCT until insert_bct or not.

  > 	The run-time number of iterations seems like it should be using
  > and/or mixed with loop preconditioning.  In this case it seems that
  > preconditioning should be orthogonal to loop unrolling (it currently is
  > intertwined with that optimization).  I don't know what to do about the
  > run-time iteration calculation currently in the BCT optimization until
  > this better calculation is implemented.  I think that the current code
  > actually is incorrect for corner cases and large iteration values, so I
  > think it probably needs to be removed altogether or at least disabled,
  > regardless of whether the better implementation is in place.
This sounds quite reasonable.


More information about the Gcc mailing list