Re: [4.5] Doloop improvement patches, 4/7

[Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>]

Hi,

> determine_max_iter has code to improve the upper bound for the number of
> iterations by constructing a condition of the form "iteration_count <
> bound", and trying to prove it true using simplify_using_initial_values.
> 
> Currently, it uses an iteration count that has already been passed
> through the same simplification.  Doing so loses opportunities for using
> conditions in the simplification.  For example,
> 
>     R6 = R7;
>     CC = R6 < -1;
>     IF !CC jump over the loop;
>   loop starts here:
>     decrement R6 and branch if not zero.
> 
> Here, the number of iterations gets simplified to R7 in the first pass
> of simplifications, but when trying to prove "R6 < -1" it is better to
> start again with an expression based on R6, not R7.
> 
> This patch relies on the previous ones to strengthen
> simplify_using_initial_values sufficiently for this to be a win in
> almost all cases.

Does it really matter, with your patch 2/7?

> 	* loop-iv.c (determine_max_iter): New arg OLD_NITER.  All callers
> 	changed.  Use this when trying to improve the upper bound.
> 	Generate the comparison by using simplify_gen_relational.
> 
> Index: loop-iv.c
> ===================================================================
> --- loop-iv.c.orig
> +++ loop-iv.c
> @@ -2100,7 +2100,7 @@ canonicalize_iv_subregs (struct rtx_iv *
>  /* Tries to estimate the maximum number of iterations.  */
>  
>  static unsigned HOST_WIDEST_INT
> -determine_max_iter (struct loop *loop, struct niter_desc *desc)
> +determine_max_iter (struct loop *loop, struct niter_desc *desc, rtx old_niter)

Document OLD_NITER in the function comments (preferably including an
example that shows how it is useful, also answering my query above).

Zdenek