This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Do not give realistic estimates for loop with array accesses
- From: "Bin.Cheng" <amker dot cheng at gmail dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: gcc-patches List <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>
- Date: Wed, 30 Mar 2016 14:24:52 +0100
- Subject: Re: Do not give realistic estimates for loop with array accesses
- Authentication-results: sourceware.org; auth=none
- References: <20160330100018 dot GA54780 at kam dot mff dot cuni dot cz>
On Wed, Mar 30, 2016 at 11:00 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> Hi,
> while looking into sudoku solving benchark, I noticed that we incorrectly
> estimate loop to iterate 10 times just because the array it traverses is of
> dimension 10. This of course is just upper bound and not realistic bound.
> Realistically those loops iterates once most of time.
>
> It turns out this bug was introduced by me in
> https://gcc.gnu.org/ml/gcc-patches/2013-01/msg00444.html
> While I do not recall doing that patch, it seems like a thinko about reliable
> (name of the variable) and realistic (name of the parameter it is passed to).
>
> Fixing this caused one testsuite fallout in predictive commoning testcase
> because loop unswitching previously disabled itself having an estimated number
> of iterations 1 (I am not sure if that is not supposed to be 0, with 1
> iteration unswithcing may pay back, little bit, I suppose it wants to test
> number of stmt executions of the condtional to be at least 2 which depends on
> whether the conditional is before or after the loop exits). This made me notice
> that some loop passes that want to give up on low trip count uses combination
> of estimated number of iterations and max number of iterations while other
> don't which is fixed here. The code combining both realistic and max counts
> is same as i.e. in unroller and other passes already.
>
> I also wonder if predictive comming is a win for loops with very low
> trip count, but that is for separate patch, too, anyway.
>
> Bootstrapped/regtested x86_64-linux, OK?
>
> Honza
>
> * tree-ssa-loop-niter.c (idx_infer_loop_bounds): We can't get realistic
> estimates here.
> * tree-ssa-loop-unswitch.c (tree_unswitch_single_loop): Use also
> max_loop_iterations_int.
> * tree-ssa-loop-ivopts.c (avg_loop_niter): Likewise.
> * tree-vect-loop.c (vect_analyze_loop_2): Likewise.
> Index: tree-ssa-loop-niter.c
> ===================================================================
> --- tree-ssa-loop-niter.c (revision 234516)
> +++ tree-ssa-loop-niter.c (working copy)
> @@ -3115,7 +3115,6 @@ idx_infer_loop_bounds (tree base, tree *
> tree low, high, type, next;
> bool sign, upper = true, at_end = false;
> struct loop *loop = data->loop;
> - bool reliable = true;
>
> if (TREE_CODE (base) != ARRAY_REF)
> return true;
> @@ -3187,14 +3186,14 @@ idx_infer_loop_bounds (tree base, tree *
> && tree_int_cst_compare (next, high) <= 0)
> return true;
>
> - /* If access is not executed on every iteration, we must ensure that overlow may
> - not make the access valid later. */
> + /* If access is not executed on every iteration, we must ensure that overlow
> + may not make the access valid later. */
> if (!dominated_by_p (CDI_DOMINATORS, loop->latch, gimple_bb (data->stmt))
> && scev_probably_wraps_p (initial_condition_in_loop_num (ev, loop->num),
> step, data->stmt, loop, true))
> - reliable = false;
> + upper = false;
>
> - record_nonwrapping_iv (loop, init, step, data->stmt, low, high, reliable, upper);
> + record_nonwrapping_iv (loop, init, step, data->stmt, low, high, false, upper);
> return true;
> }
Hi,
I have a concern that GCC records bound information from basic blocks
even that don't dominate loop latch. Given below example:
extern int b[];
void bar (int *);
int foo (int x, int n)
{
int i;
int arr[128] = {0};
for (i = 0; i < n; i++)
{
if (x > i)
{
a[i] = i;
b[i] = i;
}
}
bar (arr);
return 0;
}
The upper bound inferred from a[i] is 127. This information is
recorded along with the stmt itself in loop->bounds. Afterwards, this
information is also used in a flow-sensitive way. In this example, we
are sure that &b[i] won't overflow (thus a SCEV) because it's in the
same basic block as a[i]. GCC currently relies on such information in
overflow detection for scev, i.e., loop_exits_before_overflow.
But with this change, we won't record upper bound information in
record_estimate because the parameter is set to false?
Thanks,
bin