[compiler] ReactiveIR break node and related block structuring #32022
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adds a new BreakNode to represent breaks (and continues, though not handled yet). Along with this change, graph construction now guarantees that there is a control dependency from the terminal of a block on all not-yet-depended-upon nodes in that block. Since nodes in a block will themselves have a transitive control dependency on the block's entry node, this means that there is a transitive control or data dependency from the block terminal through to all the nodes in that block, up to the block entry. BreakNode also has a target, the node that its control would jump to. This unblocks conversion back to HIR or ReactiveFunction, and also provides the necessary information to run (abstract) interpretation using ReactiveIR. This guarantees that nodes remain ordered. It also means that all nodes will appear used, since they are guaranteed to have at least one node dependending on them, the final node of their block. Thus (despite my comments in chat), dead code elimination against ReactiveIR does actually require a bit more than just running RPO and pruning unused nodes — DCE would have to look for nodes that are only used as control nodes, ie whose actual value is unused, and remove those. But we're not planning to use this for DCE anyway so this is more of an observation about the implications for this change. [ghstack-poisoned]
This was referenced Jan 8, 2025
josephsavona
added a commit
that referenced
this pull request
Jan 8, 2025
Adds a new BreakNode to represent breaks (and continues, though not handled yet). Along with this change, graph construction now guarantees that there is a control dependency from the terminal of a block on all not-yet-depended-upon nodes in that block. Since nodes in a block will themselves have a transitive control dependency on the block's entry node, this means that there is a transitive control or data dependency from the block terminal through to all the nodes in that block, up to the block entry. BreakNode also has a target, the node that its control would jump to. This unblocks conversion back to HIR or ReactiveFunction, and also provides the necessary information to run (abstract) interpretation using ReactiveIR. This guarantees that nodes remain ordered. It also means that all nodes will appear used, since they are guaranteed to have at least one node dependending on them, the final node of their block. Thus (despite my comments in chat), dead code elimination against ReactiveIR does actually require a bit more than just running RPO and pruning unused nodes — DCE would have to look for nodes that are only used as control nodes, ie whose actual value is unused, and remove those. But we're not planning to use this for DCE anyway so this is more of an observation about the implications for this change. ghstack-source-id: e3d74a3cc118d6ded95abee2d94114ccac5319ca Pull Request resolved: #32022
facebook-github-bot
added
the
React Core Team
…ring" Extends the sea-of-nodes ReactiveIR exploration from previous PRs. Adds a new BreakNode to represent breaks (and continues, though not handled yet). Along with this change, graph construction now guarantees that there is a control dependency from the terminal of a block on all not-yet-depended-upon nodes in that block. Since nodes in a block will themselves have a transitive control dependency on the block's entry node, this means that there is a transitive control or data dependency from the block terminal through to all the nodes in that block, up to the block entry. BreakNode also has a target, the node that its control would jump to. This unblocks conversion back to HIR or ReactiveFunction, and also provides the necessary information to run (abstract) interpretation using ReactiveIR. This guarantees that nodes remain ordered. It also means that all nodes will appear used, since they are guaranteed to have at least one node dependending on them, the final node of their block. Thus (despite my comments in chat), dead code elimination against ReactiveIR does actually require a bit more than just running RPO and pruning unused nodes — DCE would have to look for nodes that are only used as control nodes, ie whose actual value is unused, and remove those. But we're not planning to use this for DCE anyway so this is more of an observation about the implications for this change. [ghstack-poisoned]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Stack from ghstack (oldest at bottom):
Extends the sea-of-nodes ReactiveIR exploration from previous PRs.
Adds a new BreakNode to represent breaks (and continues, though not handled yet). Along with this change, graph construction now guarantees that there is a control dependency from the terminal of a block on all not-yet-depended-upon nodes in that block. Since nodes in a block will themselves have a transitive control dependency on the block's entry node, this means that there is a transitive control or data dependency from the block terminal through to all the nodes in that block, up to the block entry.
BreakNode also has a target, the node that its control would jump to. This unblocks conversion back to HIR or ReactiveFunction, and also provides the necessary information to run (abstract) interpretation using ReactiveIR.
This guarantees that nodes remain ordered. It also means that all nodes will appear used, since they are guaranteed to have at least one node dependending on them, the final node of their block. Thus (despite my comments in chat), dead code elimination against ReactiveIR does actually require a bit more than just running RPO and pruning unused nodes — DCE would have to look for nodes that are only used as control nodes, ie whose actual value is unused, and remove those. But we're not planning to use this for DCE anyway so this is more of an observation about the implications for this change.