Skip to content
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

Recognize discriminant reads as no-ops in RemoveNoopLandingPads #77793

Merged
merged 1 commit into from
Oct 11, 2020

Conversation

tmiasko
Copy link
Contributor

@tmiasko tmiasko commented Oct 10, 2020

The cleanup blocks often contain read of discriminants. Teach
RemoveNoopLandingPads to recognize them as no-ops to remove
additional no-op landing pads.

The cleanup blocks often contain read of discriminants. Teach
RemoveNoopLandingPads to recognize them as no-ops to remove
additional no-op landing pads.
@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 10, 2020
@jonas-schievink
Copy link
Contributor

@bors try @rust-timer queue

@rust-timer
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Oct 10, 2020

⌛ Trying commit ecd7862 with merge 847577274ba21becb5fce245fb53d7d6a392e951...

@bors
Copy link
Contributor

bors commented Oct 10, 2020

☀️ Try build successful - checks-actions, checks-azure
Build commit: 847577274ba21becb5fce245fb53d7d6a392e951 (847577274ba21becb5fce245fb53d7d6a392e951)

@rust-timer
Copy link
Collaborator

Queued 847577274ba21becb5fce245fb53d7d6a392e951 with parent cae8bc1, future comparison URL.

@@ -43,7 +43,7 @@ impl RemoveNoopLandingPads {
// These are all nops in a landing pad
}

StatementKind::Assign(box (place, Rvalue::Use(_))) => {
StatementKind::Assign(box (place, Rvalue::Use(_) | Rvalue::Discriminant(_))) => {
if place.as_local().is_some() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder how common it is to have writes to unprojected locals that are not drop flags along the cleanup path? Seems like we could ignore these as well.

@ecstatic-morse
Copy link
Contributor

LGTM, I'd like to see a MIR opt test in which these changes have an impact, although maybe this is more speculative? I'll check back in once perf results are up.

@rust-timer
Copy link
Collaborator

Finished benchmarking try commit (847577274ba21becb5fce245fb53d7d6a392e951): 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 rollup- to bors.

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

@tmiasko
Copy link
Contributor Author

tmiasko commented Oct 10, 2020

I was examining MIR of functions making extensive use of ? together with a Result type where Err needs a drop, but Ok doesn't. The cleanup path contained mostly no-op code but it wasn't detected as such, and this was the reason why. When rebuilding the standard library, this increases the number of no-op jumps folded from 0 to 190, and no-op landing pads from 139220 to 139994. A small improvement.

I also experimented with a more aggressive variant, but that had no additional effect. Maybe someone more familiar with code generated by drop elaboration could tell if there is some particular pattern still missing, but I didn't notice any.

Regarding tests, this pass runs twice with the same name, and diff is unfortunately for the wrong one, which is why so far I didn't add any.

@ecstatic-morse
Copy link
Contributor

Got it! You could add a name to RemoveNoopLandingPads like SimplifyCfg currently has, but that's not really your responsibility, and it doesn't need to block this. r=me when you're happy.

@bors delegate+

@bors
Copy link
Contributor

bors commented Oct 10, 2020

✌️ @tmiasko can now approve this pull request

@tmiasko
Copy link
Contributor Author

tmiasko commented Oct 11, 2020

@bors r=ecstatic-morse

@jonas-schievink
Copy link
Contributor

Hmm, seems like delegation is broken

@bors r=ecstatic-morse

@bors
Copy link
Contributor

bors commented Oct 11, 2020

📌 Commit ecd7862 has been approved by ecstatic-morse

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 11, 2020
@bors
Copy link
Contributor

bors commented Oct 11, 2020

⌛ Testing commit ecd7862 with merge 8cc82ee...

@bors
Copy link
Contributor

bors commented Oct 11, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: ecstatic-morse
Pushing 8cc82ee to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 11, 2020
@bors bors merged commit 8cc82ee into rust-lang:master Oct 11, 2020
@rustbot rustbot added this to the 1.49.0 milestone Oct 11, 2020
@tmiasko tmiasko deleted the no-op-discriminant branch October 11, 2020 18:42
@Mark-Simulacrum
Copy link
Member

Excellent (2-3% instructions, <1% wall-time) improvements on several real-world benchmarks, including style-servo. Great work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants