Re: Loop optimizer tidy up

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

  In message <14387.52452.654707.101595@ongaonga.elec.canterbury.ac.nz>you writ
e:
  > Jeffrey A Law writes:
  >  > I found out why these patches were having no effect on the PPC -- they'r
  > e
  >  > only enabled with -fbranch-count-reg.  Doh!
  > 
  > Yeah, that helps.
  > 
  >  > I still haven't heard back from the last batch of comments.  I want to g
  > et the
  >  > remaining minor issues dealt with some that we can get this patch
  > integrated.
  > 
  > Here's the revised patch.
This didn't really address two of the issues I cited earlier:

	* doloop_modify knows *way* too much about the internals of the
	looping patterns.

	I believe you said earlier that the only one that can't be easily
	passed in was the comparison code.  Can you please provide more
	details why?  In the mean time, can we please pass in the rest of
	the things that doloop_modify was extracting from the loop pattern?

	* I do not see any code that verifies the increment is a power
	of two when we do runtime computation of the iteration count.  This
	needs to be addressed since an iteration count that is not a power
	of two will cause the compiler to abort in doloop_modify_runtime.


FWIW, the ppc will bootstrap with this stuff enabled.

I looked into having the mn103 use the low overhead looping support, but it's
model of low overhead loops is different enough that doloop.c isn't going to be
particularly useful.

jeff