https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90328
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |alias
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2019-05-06
CC| |rguenth at gcc dot gnu.org
Blocks| |49774
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. This is basically the "same" issue as PR89578 just applied to
analysis that looks at cross-iteration dependences. Fortunately infrastructure
is there to deal with this in a reasonably straight-forward way.
Index: tree-data-ref.c
===================================================================
--- tree-data-ref.c (revision 270847)
+++ tree-data-ref.c (working copy)
@@ -2255,6 +2255,12 @@ dr_may_alias_p (const struct data_refere
if ((TREE_CODE (addr_a) == MEM_REF || TREE_CODE (addr_a) == TARGET_MEM_REF)
&& (TREE_CODE (addr_b) == MEM_REF || TREE_CODE (addr_b) ==
TARGET_MEM_REF)
+ /* For cross-iteration dependences the cliques must be valid for the
+ whole loop, not just individual iterations. */
+ && (!loop_nest
+ || MR_DEPENDENCE_CLIQUE (addr_a) == 1
+ || (MR_DEPENDENCE_CLIQUE (addr_a)
+ == gimple_bb (DR_STMT (a))->loop_father->owned_clique))
&& MR_DEPENDENCE_CLIQUE (addr_a) == MR_DEPENDENCE_CLIQUE (addr_b)
&& MR_DEPENDENCE_BASE (addr_a) != MR_DEPENDENCE_BASE (addr_b))
return false;
the only "awkward" thing is looking at DR_STMTs BB. It would be easier to
pass down the outermost loop and possibly more correct to look at the
"common" loop enclosing both a and b. (even though DR only deals with
perfect nests this function is also used by graphite to handle DRs
in non-perfect nests)
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774
[Bug 49774] [meta-bug] restrict qualification aliasing issues
