-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Extend uninhabited enum variant branch elimination to also affect fallthrough #93387
Conversation
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
Here's the comment from the person who looked into why LLVM loses this info sometimes: #85133 (comment) That said, I do agree that making things obviously- I'm not really qualified to review this, but I can kick off a |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 27fa2feeb89a79f0b595199e5e5052d36c81335b with merge e8eeaa2ec2ea8a30bafceccf825f0ab85c50eaa0... |
let otherwise = targets.otherwise(); | ||
let bb = &body.basic_blocks()[otherwise]; | ||
if bb.statements.len() == 0 | ||
&& bb.terminator().kind == TerminatorKind::Unreachable |
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.
I always wonder about StorageLive/Dead in these.
Would it make sense for this to be, say,
if bb.terminator().kind == TerminatorKind::Unreachable
&& !bb.is_cleanup
&& bb.statements.iter().all(|s| matches!(&s.kind, StatementKind::StorageDead(_))) {
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.
Probably? I'll wait for Wesley to take a look
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.
I've changed this for now since I was fixing the other thing, but can revert this if there's a reason to prefer the other way around
Also not qualified to review this. r? rust-lang/mir-opt |
☀️ Try build successful - checks-actions |
Queued e8eeaa2ec2ea8a30bafceccf825f0ab85c50eaa0 with parent 21b4a9c, future comparison URL. |
Finished benchmarking commit (e8eeaa2ec2ea8a30bafceccf825f0ab85c50eaa0): comparison url. Summary: This benchmark run did not return any relevant results. 2 results were found to be statistically significant but too small to be relevant. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. @bors rollup=never |
27fa2fe
to
90a0081
Compare
This comment has been minimized.
This comment has been minimized.
90a0081
to
8bc43fd
Compare
...-opt/uninhabited_fallthrough_elimination.eliminate_fallthrough.UninhabitedEnumBranching.diff
Show resolved
Hide resolved
…ugh. The `uninhabited_enum_branch` miropt now also checks whether the fallthrough case is inhabited, and if not will ensure that it points to an unreachable block.
8bc43fd
to
0783009
Compare
Thanks. @bors r+ rollup=never |
📌 Commit 0783009 has been approved by |
⌛ Testing commit 0783009 with merge 26381c0af57c9f901af488e59a0c2bee8de610f1... |
💔 Test failed - checks-actions |
@bors retry x86_64-apple-2 failure without logs |
☀️ Test successful - checks-actions |
Finished benchmarking commit (a6fe969): comparison url. Summary: This benchmark run did not return any relevant results. 3 results were found to be statistically significant but too small to be relevant. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
The
uninhabited_enum_branching
mir opt eliminates branches on variants where the data is uninhabited. This change extends this pass to also ensure that theotherwise
case points to a trivially unreachable bb if all inhabited variants are present in the non-otherwise branches.I believe it was @scottmcm who said that LLVM eliminates some of this information in its SimplifyCFG pass. This is unfortunate, but this change should still be at least a small improvement in principle (I don't think it will show up on any benchmarks)