> >
> > I noticed loop-doloop.c use _int version and likely_max, maybe you want
> > that here?
> >
> > est_niter = get_estimated_loop_iterations_int (loop);
> > if (est_niter == -1)
> > est_niter = get_likely_max_loop_iterations_int (loop)
>
> I think that are two different things - get_estimated_loop_iterations_int
> are the average number of iterations while
> get_likely_max_loop_iterations_int is an upper bound. I'm not sure we
> want to use an upper bound for costing.
>
> Based on feedback from Honza I'm currently testing the variant below
> which keeps the --param and uses it to cap the estimated number of
> iterations. That makes the scaling more precise for inner loops that
> don't iterate much but keeps the --param to avoid overflow and to
> keep the present behavior when there's no reliable profile info
> available.
indeed, get_likely_max_loop_iterations_int may be very large. In some
cases it however will give useful value - for example when loop travels
small array.
So what one can use it for is to cap the --param value.
> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
> index c521b43a47c..cbdd5b407da 100644
> --- a/gcc/tree-vect-loop.c
> +++ b/gcc/tree-vect-loop.c
> @@ -1519,6 +1519,13 @@ vect_analyze_loop_form (class loop *loop,
> vec_info_shared *shared)
> stmt_vec_info inner_loop_cond_info
> = loop_vinfo->lookup_stmt (inner_loop_cond);
> STMT_VINFO_TYPE (inner_loop_cond_info) = loop_exit_ctrl_vec_info_type;
> + /* If we have an estimate on the number of iterations of the inner
> + loop use that to limit the scale for costing, otherwise use
> + --param vect-inner-loop-cost-factor literally. */
> + widest_int nit;
> + if (get_estimated_loop_iterations (loop->inner, &nit))
> + LOOP_VINFO_INNER_LOOP_COST_FACTOR (loop_vinfo)
> + = wi::smin (nit, param_vect_inner_loop_cost_factor).to_uhwi ();
if (get_estimated_loop_iterations (loop->inner, &nit))
LOOP_VINFO_INNER_LOOP_COST_FACTOR (loop_vinfo)
= wi::smin (nit, REG_BR_PROB_BASE /*or other random big cap
*/).to_uhwi ();
else if (get_likely_max_loop_iterations (loop->inner, &nit))
LOOP_VINFO_INNER_LOOP_COST_FACTOR (loop_vinfo)
= wi::smin (nit, param_vect_inner_loop_cost_factor).to_uhwi ();
else
LOOP_VINFO_INNER_LOOP_COST_FACTOR (loop_vinfo)
= param_vect_inner_loop_cost_factor;
I.e. if we really know the number of iterations, we probably want to
weight by it but we want to cap to avoid overflows. I assume if we kno
that tripcount is 10000 or more we basically do not care about damage
done to outer loop as long as iner loop improves?
If we know max number of iterations and it is smaller then the param,
we want to use it as cap.
The situation where get_estimated_loop_iteraitons returns wrong value
should be rare - basically when the loop was duplicated by inliner
(or other transform) and it behaves a lot differently then the average
execution of the loop in the train run. In this case we could also
argue that the loop is not statistically important :)
Honza
> }
>
> gcc_assert (!loop->aux);
> --
> 2.31.1
>
