-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transform post order walk to an iterative approach #78607
Conversation
The previous recursive approach might overflow the stack when walking a particularly deep, list-like, graph. In particular, dominator calculation for borrow checking does such a traversal and very long functions might lead to a region dependency graph with in this problematic structure.
r? @davidtwco (rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation LGTM, have you confirmed that this fixes the issue reported? Going to trigger a perf run to see the impact also (though if this fixes the issue, then I think we'd likely land it anyway).
@bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit af72a70 with merge b0d26b01718f8a86b4ee8dfdb0508d3a5d49e19b... |
Unfortunately there is no simplified reproduction. It's not entirely clear to me how build it and the file does appear to have dependencies. In any case, if there's any perf trouble I would like to try out a small-vec solution before admitting a regression in the fix. |
☀️ Try build successful - checks-actions |
Queued b0d26b01718f8a86b4ee8dfdb0508d3a5d49e19b with parent 234099d, future comparison URL. |
Finished benchmarking try commit (b0d26b01718f8a86b4ee8dfdb0508d3a5d49e19b): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
Looks good to me. @bors r+ |
📌 Commit af72a70 has been approved by |
☀️ Test successful - checks-actions |
Adding |
The previous recursive approach might overflow the stack when walking a
particularly deep, list-like, graph. In particular, dominator
calculation for borrow checking does such a traversal and very long
functions might lead to a region dependency graph with in this
problematic structure.
This addresses what appears to be the cause of #78567 (@SunHao-0 thanks for the stack trace).