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

Clean up MIR drop generation #61872

Merged
merged 6 commits into from
Jun 26, 2019
Merged

Conversation

matthewjasper
Copy link
Contributor

@matthewjasper matthewjasper commented Jun 15, 2019

  • Don't assign twice to the destination of a while loop containing a break expression
  • Use as_temp to evaluate statement expression
  • Avoid consecutive StorageLives for the condition of a while loop
  • Unify return, break and continue handling, and move it to scopes.rs
  • Make some of the scopes.rs internals private
  • Don't use Places that are always Locals in MIR drop generation

Closes #42371
Closes #61579
Closes #61731
Closes #61834
Closes #61910
Closes #62115

@rust-highfive
Copy link
Collaborator

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 15, 2019
@matthewjasper matthewjasper changed the title Refactor MIR drop generation Clean up MIR drop generation Jun 15, 2019
@@ -179,20 +179,19 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
// conduct the test, if necessary
let body_block;
if let Some(cond_expr) = opt_cond_expr {
Copy link
Contributor

Choose a reason for hiding this comment

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

N.B. As part of implementing while a && let b = c { ... } I'll make a PR to remove hir::ExprKind::While and then hair::ExprKind::Loop will presumably need to drop it's condition field and so the else branch would be floated out and the if branch would be removed... I hope the changes here do not cause problems for this...?

Copy link
Contributor Author

@matthewjasper matthewjasper Jun 15, 2019

Choose a reason for hiding this comment

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

That should be fine, this is only a problem because while loops are special cased. For any sensible HIR lowering this won't be a problem. The temporary will probably end up storage-live for the whole loop body, but that isn't observable. The following two functions generate almost identical optimized MIR after this PR, for example.

fn while_loop(c: bool) {
    while get_bool(c) {
        if get_bool(c) {
            break;
        }
    }
}

// What the above should probably expand to
fn exp_while_loop(c: bool) {
    loop {
        match get_bool(c) {
            true => {
                {if get_bool(c) {
                    break;
                }}
                continue;
            }
            _ => {}
        }
        break;
    }
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Cool.

For any sensible HIR lowering this won't be a problem.

Specifically, the HIR lowering should likely be:

'label: while $cond $block

==>

'label: loop {
    match DropTemps($cond) {
        true => $block,
        _ => break,
    }
}

(is there a particular reason you are using continue; and an empty block?)

Copy link
Contributor Author

@matthewjasper matthewjasper Jun 15, 2019

Choose a reason for hiding this comment

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

It's slightly closer to what the RFC specified. What you're suggesting is probably better.

Copy link
Contributor

Choose a reason for hiding this comment

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

This should be unnecessary now with #61988.

@bors
Copy link
Contributor

bors commented Jun 16, 2019

☔ The latest upstream changes (presumably #60730) made this pull request unmergeable. Please resolve the merge conflicts.

@bors
Copy link
Contributor

bors commented Jun 18, 2019

☔ The latest upstream changes (presumably #61915) made this pull request unmergeable. Please resolve the merge conflicts.

@eddyb
Copy link
Member

eddyb commented Jun 18, 2019

r? @pnkfelix

Copy link
Contributor

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

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

This looks very good. I left a few questions.

src/librustc_mir/build/expr/stmt.rs Show resolved Hide resolved
src/librustc_mir/build/matches/mod.rs Show resolved Hide resolved
src/librustc_mir/build/expr/stmt.rs Show resolved Hide resolved
src/test/mir-opt/while-storage.rs Show resolved Hide resolved
src/librustc_mir/build/expr/as_rvalue.rs Show resolved Hide resolved
@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Jun 25, 2019

📌 Commit 07e5297faf2966a77c466b0b5ad936c0deb828ac has been approved by nikomatsakis

@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 Jun 25, 2019
@bors
Copy link
Contributor

bors commented Jun 25, 2019

☔ The latest upstream changes (presumably #62119) made this pull request unmergeable. Please resolve the merge conflicts.

@cramertj
Copy link
Member

@bors r=nikomatsakis

@bors
Copy link
Contributor

bors commented Jun 26, 2019

📌 Commit 3131427 has been approved by nikomatsakis

@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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jun 26, 2019
@bors
Copy link
Contributor

bors commented Jun 26, 2019

⌛ Testing commit 3131427 with merge d3e2cec...

bors added a commit that referenced this pull request Jun 26, 2019
…sakis

Clean up MIR drop generation

* Don't assign twice to the destination of a `while` loop containing a `break` expression
* Use `as_temp` to evaluate statement expression
* Avoid consecutive `StorageLive`s for the condition of a `while` loop
* Unify `return`, `break` and `continue` handling, and move it to `scopes.rs`
* Make some of the `scopes.rs` internals private
* Don't use `Place`s that are always `Local`s in MIR drop generation

Closes #42371
Closes #61579
Closes #61731
Closes #61834
Closes #61910
Closes #62115
@bors
Copy link
Contributor

bors commented Jun 26, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: nikomatsakis
Pushing d3e2cec to master...

@mati865
Copy link
Contributor

mati865 commented Jul 3, 2019

@matthewjasper matthewjasper deleted the refactor-mir-drop-gen branch July 7, 2019 09:48
@matthewjasper
Copy link
Contributor Author

The ctfe-stress benchmark is now generating more MIR, so I'm not surprised that it's slower. I can't really work out what's going on with unicode_normalization, since the generated MIR is unchanged for the large functions and constants.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 12, 2022
…_mention, r=compiler-errors

Fixup method doc that mentions removed param

The param was removed in rust-lang#61872 (101a2f5)
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
9 participants