Re: [patch] Speed up # of iterations analysis

[Paul Schlie <schlie at comcast dot net>]

> From: Daniel Berlin <dberlin@dberlin.org>
>> yes, was just agreeing/observing since doing so and applying the result as
>> in #3 above, isn't likely as preferable as alternative optimizations which
>> don't rely on determining the number of iterations of a loop;
> 
> Do you have any data to back this up?
> 
> There are plenty of very powerful loop transformations that require
> knowing the number of iterations of a loop.
> 
> Claiming that "alternative optimizations" will work just as well seems a
> bit far fetched.

the comment was specific to the optimization referenced as item #3 which
specifically notes the elimination of simplify_using_outer_evolutions which
was described as attempting to benefit from re-using the terminal loop count
value from a previous loop (basically attempting save the re-initialization
of a loop count variable, most likely beneficial to very small loops likely
unrolled anyway); which although good, only occurs once per loop vs. other
optimizations which may simplify the loop count comparison occurring each
iteration, therefore likely more significant in this particular case; with
no conclusions meant to be implied toward other potentially more significant
optimizations which could benefit from loop iteration knowledge.

(just to be clear, my thoughts with respect to #3 are based on a presumption
 that a comparison of a value against 0 is typically cheaper than that
 otherwise required to compare a computed value against an arbitrarily
 large constant; either in the instruction size required to immediately
 reference it, or requiring it first be itself loaded, thereby likely
 defeating any significant saving's associated with not requiring the
 initialization of the count to begin with; not to mention that some targets
 may leverage a previously computed implied comparison of an operation's
 result against 0 for free, which the #3 optimization could possibly make
 more difficult to take advantage of, as the loop count's initial value
 becomes seemingly dependant on the previous count variable's state, thereby
 potentially obscuring the true simple nature of the loop itself?)