https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77605
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |spop at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
And the reason is IMHO
/* Determines the overlapping elements due to accesses CHREC_A and
CHREC_B, that are affine functions. This function cannot handle
symbolic evolution functions, ie. when initial conditions are
parameters, because it uses lambda matrices of integers. */
static void
analyze_subscript_affine_affine (tree chrec_a,
tree chrec_b,
conflict_function **overlaps_a,
conflict_function **overlaps_b,
tree *last_conflicts)
{
...
if (i1 > 0 && j1 > 0)
{
HOST_WIDE_INT niter_a
= max_stmt_executions_int (get_chrec_loop (chrec_a));
HOST_WIDE_INT niter_b
= max_stmt_executions_int (get_chrec_loop (chrec_b));
HOST_WIDE_INT niter = MIN (niter_a, niter_b);
^^^
...
/* If the overlap occurs outside of the bounds of the
loop, there is no dependence. */
if (x1 >= niter || y1 >= niter)
we compute the conflict iteration pair to 0, 6 but niter is two here
(minimum of two and eight).
Changing the above tests to use niter_a and niter_b fixes the issue but we have
other niter uses above that. And the question is of course how to represent
"last_conflict" here -- it is supposed to be an iteration number which
hopefully is in-range for both loops (fixing the above code to properly
use niter_a/b makes it so for _this_ case). "last_conflicts" is not very
well documented ("This field stores the information about the iteration domain
validity of the dependence relation.").
Patch that needs testing (and a 2nd eye):
Index: gcc/tree-data-ref.c
===================================================================
--- gcc/tree-data-ref.c (revision 240176)
+++ gcc/tree-data-ref.c (working copy)
@@ -2686,13 +2682,13 @@ analyze_subscript_affine_affine (tree ch
if (niter > 0)
{
- HOST_WIDE_INT tau2 = MIN (FLOOR_DIV (niter - i0, i1),
- FLOOR_DIV (niter - j0, j1));
+ HOST_WIDE_INT tau2 = MIN (FLOOR_DIV (niter_a - i0, i1),
+ FLOOR_DIV (niter_b - j0, j1));
HOST_WIDE_INT last_conflict = tau2 - (x1 - i0)/i1;
/* If the overlap occurs outside of the bounds of the
loop, there is no dependence. */
- if (x1 >= niter || y1 >= niter)
+ if (x1 >= niter_a || y1 >= niter_b)
{
*overlaps_a = conflict_fn_no_dependence ();
*overlaps_b = conflict_fn_no_dependence ();
with this patch we get
(compute_affine_dependence
stmt_a: _2 = c[b.5_22][_1];
stmt_b: c[b.5_22][a.7_23] = _3;
(analyze_overlapping_iterations
(chrec_a = {6, +, 1}_2)
(chrec_b = {0, +, 1}_1)
(analyze_miv_subscript
(analyze_subscript_affine_affine
(overlaps_a = [0 + 1 * x_1])
(overlaps_b = [6 + 1 * x_1]))
)
(overlap_iterations_a = [0 + 1 * x_1])
(overlap_iterations_b = [6 + 1 * x_1]))
(analyze_overlapping_iterations
(chrec_a = {0, +, 1}_2)
(chrec_b = {0, +, 1}_2)
(overlap_iterations_a = [0])
(overlap_iterations_b = [0]))
(Dependence relation cannot be represented by distance vector.)
)
The issue was likely introduced by r129797 (not sure if we vectorized the loop
immediately after that change).
