https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107323
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amker at gcc dot gnu.org
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, so we seem to get unresolved dependences for which we insert an alias check
but then we end up somewhat randomly ordering partitions, first clearing B[],
then doing the non-clearing part of the loop and then afterwards the
clearing of A[] (which is the issue).
I think the issue is that in this case we have a WAW dependence and a
RAW dependence that can be resolved with an alias check. Initially all
three partitions are in the same SCC and thus get "random" postorder.
But when resolving alias dependences that gets rectified - but for some
reason we restore the "corrupted" postorder from the random one before
sorting after it.
The comments in loop_distribution::break_alias_scc_partitions seem to
contradict themselves here:
/* Collect data dependences for runtime alias checks to break SCCs. */
if (bitmap_count_bits (sccs_to_merge) != (unsigned) num_sccs)
{
/* Record the postorder information which will be corrupted by next
graph SCC finding call. */
for (i = 0; i < pg->n_vertices; ++i)
cbdata.vertices_post[i] = pg->vertices[i].post;
/* Run SCC finding algorithm again, with alias dependence edges
skipped. This is to topologically sort partitions according to
compilation time known dependence. Note the topological order
is stored in the form of pg's post order number. */
num_sccs_no_alias = graphds_scc (pg, NULL, pg_skip_alias_edge);
not "fixing" the postorder resolves this PR.
The restoring of postorder was done to fix PR95638 where previously a
fix for PR94125 tried to fix the case where we merge all partitions in
a SCC but the postorder of the prevailing partiton got it scheduled
wrongly (I don't see how that can happen though). Unfortunately
the testcase no longer triggers the late partition merging.
But clearly simply restoring the original postorder is wrong here.
I need to go back and revisit PR94125 when it was reproducible, it
was fixed with r10-7184-ge4e9a59105a81c
