JIT: Switch DataFlow::ForwardAnalysis to be RPO based
#111653
Merged
Conversation
This file contains hidden or 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
`DataFlow::ForwardAnalysis` used a worklist based algorithm where it kept visiting successor blocks as long as information was being propagated until closure. However, this successor-based visit was using regular successors only, which does not account for EH second-pass flow. This was not generally a correctness problem as the only users of this class are CSE and assertion prop, and neither of them have a correctness requirement of propagating facts along filter -> finally/fault edges, but the imprecision in the modelling could result in disagreements in reachability with the DFS visit. Concretely we could end up with CSE's availability analysis finding that a nested finally/fault block was unreachable (because its corresponding try-entry was unreachable), while the DFS visit considered it reachable due to a spurious filter predecessor. This mismatch meant that the handler was never visited by the CSE dataflow which would result in all CSEs in some of the handler blocks being marked as available. We would then end up creating a use in one of these blocks, which SSA updating would not be able to find a corresponding def for. Fix the situation by switching `DataFlow::ForwardAnalysis` to compute a DFS tree and computing the closure based on its RPO. Fix dotnet#111345
3 tasks
Member
Author
|
/azp run runtime-coreclr superpmi-diffs |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Member
Author
|
cc @dotnet/jit-contrib PTAL @AndyAyersMS No diffs except some nice TP improvements. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
DataFlow::ForwardAnalysisused a worklist based algorithm where it kept visiting successor blocks as long as information was being propagated until closure. However, this successor-based visit was using regular successors only, which does not account for EH second-pass flow.This was not generally a correctness problem as the only users of this class are CSE and assertion prop, and neither of them have a correctness requirement of propagating facts along filter -> finally/fault edges, but the imprecision in the modelling could result in disagreements in reachability with the DFS visit.
Concretely we could end up with CSE's availability analysis finding that a nested finally/fault block was unreachable (because its corresponding try-entry was unreachable), while the DFS visit considered it reachable due to a spurious filter predecessor. This mismatch meant that the handler was never visited by the CSE dataflow which would result in all CSEs in some of the handler blocks being marked as available. We would then end up creating a use in one of these blocks, which SSA updating would not be able to find a corresponding def for.
Fix the situation by switching
DataFlow::ForwardAnalysisto compute a DFS tree and computing the closure based on its RPO.Fix #111345