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

Combine HaveBeenBorrowedLocals and IndirectlyMutableLocals into one dataflow analysis #69113

Merged
merged 12 commits into from
Feb 19, 2020

Conversation

ecstatic-morse
Copy link
Contributor

@ecstatic-morse ecstatic-morse commented Feb 12, 2020

This PR began as an attempt to port HaveBeenBorrowedLocals to the new dataflow framework (see #68241 for prior art). Along the way, I noticed that it could share most of its code with IndirectlyMutableLocals and then found a few bugs in the two analyses:

  • Neither one marked locals as borrowed after an Rvalue::AddressOf.
  • IndirectlyMutableLocals was missing a minor fix that HaveBeenBorrowedLocals got in Make MIR drop terminators borrow the dropped location #61069. This is not a problem today since it is only used during const-checking, where custom drop glue is forbidden. However, this may change some day.

I decided to combine the two analyses so that they wouldn't diverge in the future while ensuring that they remain distinct types (called MaybeBorrowedLocals and MaybeMutBorrowedLocals to be consistent with the Maybe{Un,}InitializedPlaces naming scheme). I fixed the bugs and switched to exhaustive matching where possible to make them less likely in the future. Finally, I added comments explaining some of the finer points of the transfer function for these analyses (see #61069 and #65006).

This impl is temporary and will be removed along with the old dataflow
framework. It allows us to reuse the transfer function of new dataflow
analyses when defining old ones
`MaybeMutBorrowedLocals` serves the same purpose and has a better name.
This uses the new `MaybeMutBorrowedLocals` pass but we keep the
`rustc_peek_indirectly_mutable` since the two are interchangable except
when inspecting a local after it has been marked `StorageDead`.
It should have the same semantics as `HaveBeenBorrowedLocals`
@rust-highfive
Copy link
Collaborator

r? @davidtwco

(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 Feb 12, 2020
@rust-highfive

This comment has been minimized.

@rust-highfive

This comment has been minimized.

@ecstatic-morse
Copy link
Contributor Author

cc @pnkfelix. This is the follow-up to #68241 and re-enables the peek test for IndirectlyMutableLocals (now called MaybeMutBorrowedLocals).

@davidtwco
Copy link
Member

r? @wesleywiser

@wesleywiser
Copy link
Member

@ecstatic-morse Do you there there is the possibility for a compiler performance change here? Should we do a perf run before landing this?

@ecstatic-morse
Copy link
Contributor Author

ecstatic-morse commented Feb 17, 2020

@wesleywiser It is unlikely. Switching from the old to the new framework for the "initialized places" analyses yielded very small gains, but the "borrowed" analyses are used only for const-checking and generators respectively. The perf queue is a bit full right now, otherwise I would do one just in case. Perhaps rollup=never is sufficient?

Copy link
Member

@wesleywiser wesleywiser left a comment

Choose a reason for hiding this comment

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

Looks great to me!

@wesleywiser
Copy link
Member

@bors r+ rollup=never

@bors
Copy link
Contributor

bors commented Feb 18, 2020

📌 Commit 077a93c has been approved by wesleywiser

@bors
Copy link
Contributor

bors commented Feb 18, 2020

🌲 The tree is currently closed for pull requests below priority 100, this pull request will be tested once the tree is reopened

@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 Feb 18, 2020
@Dylan-DPC-zz
Copy link

@bors p=1

@bors
Copy link
Contributor

bors commented Feb 19, 2020

⌛ Testing commit 077a93c with merge 3a8108d...

bors added a commit that referenced this pull request Feb 19, 2020
…sleywiser

Combine `HaveBeenBorrowedLocals` and `IndirectlyMutableLocals` into one dataflow analysis

This PR began as an attempt to port `HaveBeenBorrowedLocals` to the new dataflow framework (see #68241 for prior art). Along the way, I noticed that it could share most of its code with `IndirectlyMutableLocals` and then found a few bugs in the two analyses:
- Neither one marked locals as borrowed after an `Rvalue::AddressOf`.
- `IndirectlyMutableLocals` was missing a minor fix that `HaveBeenBorrowedLocals` got in #61069. This is not a problem today since it is only used during const-checking, where custom drop glue is forbidden. However, this may change some day.

I decided to combine the two analyses so that they wouldn't diverge in the future while ensuring that they remain distinct types (called `MaybeBorrowedLocals` and `MaybeMutBorrowedLocals` to be consistent with the `Maybe{Un,}InitializedPlaces` naming scheme). I fixed the bugs and switched to exhaustive matching where possible to make them less likely in the future. Finally, I added comments explaining some of the finer points of the transfer function for these analyses (see #61069 and #65006).
@bors
Copy link
Contributor

bors commented Feb 19, 2020

☀️ Test successful - checks-azure
Approved by: wesleywiser
Pushing 3a8108d to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Feb 19, 2020
@bors bors merged commit 077a93c into rust-lang:master Feb 19, 2020
@ecstatic-morse ecstatic-morse deleted the unified-dataflow-borrowed branch October 6, 2020 01:42
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.

6 participants