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