Re: Loop optimizer tidy up

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

 In message <14402.15074.48343.295477@ongaonga.elec.canterbury.ac.nz>you write
:
  > Jeffrey A Law writes:
  >  > 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.
  > 
  > Yes, I was burnt by the recent changes to gen_sequence, since it no
  > longer returns the pattern for a JUMP_INSN.
  > 
  > As I said in my previous post, I am unsure as to how this should be
  > corrected.  
  > 
  > In essence, the looping condition needs to be extracted from the
  > pattern.  I suppose get_condition could be beefed up to do this.
  > Although one could argue that get_condition knows way too much about
  > the internals of jump patterns ;-)  Comments?
Instead of looking at precise locations in the pattern, we could search for
the first comparison operator in the pattern.  That loses if the pattern has
multiple comparison operators and the first isn't the one we care about.  But,
Iwould expect that to be extremely rare (and we can conditionally check for it
under ENABLE_CHECKING).

Just so I understand, the reason we can't pass it in is we give the backend
an iteration count and depend on the backend to cons up a suitable condition.
Right?


  >  > 	* 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.
  > 
  > In my previous post on this thread I explained how this was caught by
  > precondition_loop_p and showed an extract of the comment code in
  > doloop.c to handle this case.  Here's an example .loop fragment...
Sorry, I must have completely missed it.    Thanks.

jeff