This is an archive of the discontinued LLVM Phabricator instance.

[SelectionDAG] Fix behavior topological ordering with regards to glued nodes.
AbandonedPublic

Authored by niravd on Oct 10 2018, 1:21 PM.

Details

Reviewers
bogner
jyknight
Summary

Because glued nodes must be scheduled consecutively, glued User nodes
have an implicit ordering dependance to other predecessors of nodes
using their glue output. This fact is not captured in the topological
order constructed by AssignTopologicalOrder nor the precessor search
which uses this information to prune the search space, which results
in constructing cycles.

This patch fixes this by:

  1. Modifying the order construction to defer assigning an id to glue nodes until after all assignable non-glue nodes have been selected
  2. Having predecessor search explicitly search down a node's glue chain to find such indirect dependencies.

Diff Detail

Event Timeline

niravd created this revision.Oct 10 2018, 1:21 PM

The approach in general looks good to me, however I don't think this interacts correctly with the TopologicalPrune optimization.

(At this time, I'm not familiar enough with the code to intuitively know in which direction the topological sorting is used, but one of the two scenarios below will apply).

Assume that the optimization limits the nodes to be consider to the range [a, b].

Scenario 1) A non-glue edge goes past a to a node n. Since n is outside the range considered, it won't be processed even though it may have reverse glue edges back into the range.

Scenario 2) A reverse glue edge goes past b to a node m. Since m is outside the range considered, it won't be processed even though it may have normal edges back into the range.

niravd added a comment.EditedOct 11 2018, 10:44 AM

Good point. Scenario 1 may happen if we have nodes A, B, C, GlueOp, and GlueUser such that there's uses (A-> GlueUse, GlueOp->GlueUser, GlueOp->B, B-> C) and the node id ordering is GOp < B < A < GU < C then checking if A is a predecessor to C would stop searching at B and fail to see the remaining. I am unsure if this is possible currently given our id scheme, but I'll take a look. I believe it will always bias towards selecting A before B.

If it's not safe, we can preclude this case by labeling Glued node should have the same node id.

Scenario 2 is not possible as m is +infinity.

niravd updated this revision to Diff 169872.Oct 16 2018, 11:47 AM
niravd retitled this revision from [SelectionDAG] Fix behavior of glued nodes in hasPredecessorHelper. to [SelectionDAG] Fix behavior topological ordering with regards to glued nodes..
niravd edited the summary of this revision. (Show Details)

Fix topological ordering construction to prevent premature pruning.

niravd edited the summary of this revision. (Show Details)Oct 16 2018, 11:47 AM
niravd edited the summary of this revision. (Show Details)
TimNN removed a reviewer: TimNN.Nov 1 2018, 11:33 PM

I don't think I can help here any more. The changes to hasPredecessorHelper look good to me an definitely fix the original problem. However I don't know enough about the surrounding code to comment on the changes in AssignTopologicalOrder.

TimNN added a subscriber: TimNN.Nov 1 2018, 11:33 PM
niravd abandoned this revision.Mar 26 2019, 8:21 AM

Summarizing offline discussion with jyknight for future reference:

This should only be necessary due to glued nodes that are not Copy{To,From}Reg and which have additional predecessors/successors than nodes on the glue.
This appear to only occur in the case of ADDC/ADDE nodes have been deprecated.

This patch was originally written for such an instance in the AVR backend.

Herald added a project: Restricted Project. · View Herald TranscriptMar 26 2019, 8:21 AM
Herald added a subscriber: jdoerfert. · View Herald Transcript