Hi,
> > Would it be possible to add the handling of these cases
> > to estimate_numbers_of_iterations, rather than doing it just for ivopts?
>
> Yes, I did that now.
>
> Thanks,
> - Tom
>
> 2011-05-05 Tom de Vries <t...@codesourcery.com>
>
> PR target/45098
> * tree-ssa-loop-niter.c (infer_loop_bounds_from_pointer_arith): New
> function.
> (infer_loop_bounds_from_undefined): Use new function.
this is OK.
> * tree-ssa-loop-ivopts.c (may_eliminate_iv): Fix
> estimated_loop_iterations comparison.
I don't think this part is correct, though:
> Index: gcc/tree-ssa-loop-ivopts.c
> ===================================================================
> --- gcc/tree-ssa-loop-ivopts.c (revision 173734)
> +++ gcc/tree-ssa-loop-ivopts.c (working copy)
> @@ -4391,8 +4391,13 @@ may_eliminate_iv (struct ivopts_data *da
> {
> if (!estimated_loop_iterations (loop, true, &max_niter))
> return false;
> - /* The loop bound is already adjusted by adding 1. */
> - if (double_int_ucmp (max_niter, period_value) > 0)
> + /* The max iterations applies also to the number of times the
> loop
> + exit condition is executed. The number of distinct values
> of
> + the cand is period_value + 1. So, test for
> + 'period_value + 1 >= max_iterations'.
> + */
> + period_value = double_int_add (period_value, double_int_one);
> + if (double_int_ucmp (max_niter, period_value) > 0)
> return false;
> }
> else
max_niter is the upper bound on the number of iterations of the loop, i.e., the
number
of executions of its latch edge. Therefore, the control induction variable of
the loop
will (at the exit statement) achieve at most max_niter + 1 different values.
Conversely,
the number of distinct values that the control iv can represent is period + 1
(naming of
the "period" variable is a bit missleading). Thus, the correct test is
# of available values >= # of required values, equivalently
period + 1 >= max_niter + 1, equivalently
period >= max_niter, i.e.,
the current test.
Zdenek
