Bug 32075 - can't determine dependence between p->a[x+i] and p->a[x+i+1] where x is invariant but defined in the function
Summary: can't determine dependence between p->a[x+i] and p->a[x+i+1] where x is invar...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.3.0
: P3 enhancement
Target Milestone: 4.3.0
Assignee: Andrew Pinski
URL:
Keywords: missed-optimization
Depends on:
Blocks: 32375 32379 32457
  Show dependency treegraph
 
Reported: 2007-05-24 22:56 UTC by Andrew Pinski
Modified: 2007-06-24 04:07 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-05-25 02:05:50


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2007-05-24 22:56:13 UTC
While looking into some failures on the pointer plus branch after fixing up
forwprop, I noticed that we would get a failure in the vectorizer testsuite and
the reason is because we no longer could determine dependence for the two data
accesses.

Here is the testcase which is a modified version of vect-102.c which gets us
the same IR as what the pointer plus branch gives:
/* { dg-require-effective-target vect_int } */

#include <stdlib.h>
#include <stdarg.h>
#include "tree-vect.h"

#define N 9

struct extraction
{
  int a[N];
  int b[N];
};

static int a[N] = {1,2,3,4,5,6,7,8,9};
static int b[N] = {2,3,4,5,6,7,8,9,9};

int main1 (int x, int y) {
  int i;
  unsigned x1 = x;  
  struct extraction *p;
  p = (struct extraction *) malloc (sizeof (struct extraction));

  for (i = 0; i < N; i++)
    {
       p->a[i] = a[i];
       if (x == 135)
         abort (); /* to avoid vectorization  */
    }

  /* Not vectorizable: distance 1.  */
  for (i = 0; i < N - 1; i++)
    {
       p->a[x1 + i] = p->a[x1 + i + 1];
    }

  /* check results: */
  for (i = 0; i < N; i++)
    {
       if (p->a[i] != b[i])
         abort();
    }
  return 0;
}

int main (void)
{ 
  check_vect ();

  return main1 (0, N);
}

/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 0 "vect" } } */
/* { dg-final { scan-tree-dump-times "possible dependence between data-refs" 1
"vect" } } */
/* { dg-final { cleanup-tree-dump "vect" } } */

-------------------------- cut ---------------
if you change the 1 to 8, we should be able to vectorize that loop too.

Note I was wrong in PR 31995, that we got the same IR for that testcase as we got for this bug, I had missed the cast in the IR.  Anyways this is represenative of what the IR looks like for the testcase on the pointer plus branch.
Comment 1 Andrew Pinski 2007-05-25 02:05:50 UTC
Ok, I have a patch for this issue, I am going to test it with -ftree-vectorize -msse2 while bootstrapping too to make sure that we don't have really any regression due to data reference going wrong (the previous patch I should have done the same too).
Comment 2 Dorit Naishlos 2007-06-18 11:03:54 UTC
I see this in the vectorizer dump file (with mainline from a few days ago):

(compute_affine_dependence
  (stmt_a =
D.3027_19 = p_7->a[D.3026_18])
  (stmt_b =
p_7->a[D.3025_17] = D.3027_19)
Data ref a:
(Data Ref:
  stmt: D.3027_19 = p_7->a[D.3026_18];
  ref: p_7->a[D.3026_18];
  base_object: p_7->a[0];
  Access function 0: {x1_5 + 1, +, 1}_2
  Access function 1: 0B
)
Data ref b:
(Data Ref:
  stmt: p_7->a[D.3025_17] = D.3027_19;
  ref: p_7->a[D.3025_17];
  base_object: p_7->a[0];
  Access function 0: {x1_5, +, 1}_2
  Access function 1: 0B
)
affine dependence test not usable: access function not affine or constant.
(dependence classified: scev_not_known)
)

(In reply to comment #1)
> Ok, I have a patch for this issue, I am going to test it with -ftree-vectorize

so how is that coming along? do you think it will also address PRs 32375/6/7/8/9 ?
Comment 3 Sebastian Pop 2007-06-20 16:57:50 UTC
Subject: Re:  can't determine dependence between p->a[x+i] and p->a[x+i+1] where x is invariant but defined in the function

The problem has been introduced in version 124927.

@@ -3182,7 +3182,7 @@ access_functions_are_affine_or_constant_

   for (i = 0; VEC_iterate (tree, fns, i, t); i++)
     if (!evolution_function_is_constant_p (t)
-	&& !evolution_function_is_affine_multivariate_p (t))
+	&& !evolution_function_is_affine_multivariate_p (t, 0))
       return false;

   return true;

The problem is that this line is saying that t has to be an affine
function with respect to the outermost loop_0.  That means {x, +, 1}_2
with x defined in loop_0, will be considered as non affine, just
because x is varying in loop_0.  So in the above patch, we have to
replace all these zeros with some other loop number...
Comment 4 Sebastian Pop 2007-06-20 23:42:38 UTC
Subject: Bug 32075

Author: spop
Date: Wed Jun 20 23:42:28 2007
New Revision: 125900

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125900
Log:
	PR tree-optimization/32075
	* tree-data-ref.c (subscript_dependence_tester_1, 
	analyze_miv_subscript, analyze_overlapping_iterations,
	add_distance_for_zero_overlaps, build_classic_dist_vector,
	subscript_dependence_tester_1, analyze_overlapping_iterations,
	subscript_dependence_tester, access_functions_are_affine_or_constant_p,
	compute_affine_dependence, compute_all_dependences): Pass loop_nest 
	to evolution_function_is_affine_multivariate_p.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-data-ref.c

Comment 5 Sebastian Pop 2007-06-20 23:45:06 UTC
Subject: Bug 32075

Author: spop
Date: Wed Jun 20 23:44:56 2007
New Revision: 125901

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125901
Log:
	PR tree-optimization/32075
	* tree-data-ref.c (subscript_dependence_tester_1, 
	analyze_miv_subscript, analyze_overlapping_iterations,
	add_distance_for_zero_overlaps, build_classic_dist_vector,
	subscript_dependence_tester_1, analyze_overlapping_iterations,
	subscript_dependence_tester, access_functions_are_affine_or_constant_p,
	compute_affine_dependence, compute_all_dependences): Pass loop_nest 
	to evolution_function_is_affine_multivariate_p.


Modified:
    trunk/gcc/ChangeLog

Comment 6 Uroš Bizjak 2007-06-21 21:05:21 UTC
(In reply to comment #4)

> Author: spop
> Date: Wed Jun 20 23:42:28 2007
> New Revision: 125900

This commit causes PR32457.
Comment 7 Andrew Pinski 2007-06-24 04:07:44 UTC
Fixed.