https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116768
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so I think I understand what add_outer_distances does. Note for other
PRs we have a similar issue with respect to inner loops.
For
for (int i = 0; i < n; ++i)
a[0] = a[0] + i;
the WAR dependence a[0] vs a[0] had a distance vector of (1) before the
offending revision (the next iteration will access the same data) but
(0) after (the same iteration will access the same data).
For the PR101009 testcase we see
for (..)
{
g[1].b = 2;
g[1].c = 1;
*f.0_1 = g[1];
}
and the dependence between g[1].c and g[1] is computed as (1) before and
(0) after. Interestingly for
for (int i = 0; i < n; ++i)
a[i] = a[i] + 1;
we'll have a distance vector of (0) (with or without the change). The
intent for add_outer_distances is likely for
for (int j = 0; j < n; ++j)
for (int i = 0; i < n; ++i)
a[i] = a[i] + 1;
to have ( 0 1 ) here. Note that for
for (int j = 0; j < n; ++j)
for (int i = 0; i < n; ++i)
a[j] = a[j] + 1;
we end up with ( 0 0 ) patched or unpatched, so the offending change
makes the behavior more consistent IMO.
In fact build_classic_dist_vector special-cases same_access_functions (ddr)
by building a ( 0 ... 1 ) distance vector for all-invariant access functions.
That behavior didn't change with the offending rev and thus is now
inconsistent.
