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

Stop considering moved-out locals when computing auto traits for generators #112279

Closed
wants to merge 2 commits into from

Conversation

nbdd0121
Copy link
Contributor

@nbdd0121 nbdd0121 commented Jun 4, 2023

Addresses #94067 (but does not fix it since drop-tracking-mir is unstable)

This PR, unlike #110420 or #112050, does not attempt to reduce the number of live locals across suspension points. It however ignores moved-out locals for trait purposes. So this PR solves the non-send issue, but not the size issue.

Suggested by @RalfJung in rust-lang/unsafe-code-guidelines#188

cc @b-naber who's working on this from a different perspective.

r? @cjgillot

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 4, 2023
@rustbot
Copy link
Collaborator

rustbot commented Jun 4, 2023

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Comment on lines 960 to 963
if !init_locals.contains(local) {
// If only the storage is required to be live, but local is not initialized, then we can
// ignore such type for auto trait purposes.
true
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we require storage to be live if the locals is not initialized? Should the general algorithm be changed to avoid requiring storage? That'd kill 2 birds with one stone: the spurious auto trait limitation and the generator size.

As a general rule, I'd rather keep the "storage" and the "traits" algorithm as close to each other as possible: any deviation between the two is a potential source of unsoundness. This exact change is probably not, but the general rule should stand.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's currently an open question rust-lang/unsafe-code-guidelines#188 and is much harder to solve.

@cjgillot
Copy link
Contributor

cjgillot commented Jul 8, 2023

There is a meeting on july 24th to discuss soundness of -Zdrop-tracking-mir. I'm waiting for this meeting before doing any review here.

@bors
Copy link
Contributor

bors commented Aug 9, 2023

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

@nbdd0121
Copy link
Contributor Author

What's the outcome from the meeting?

@cjgillot
Copy link
Contributor

cjgillot commented Aug 24, 2023

The meeting happened and decided to stabilize -Zdrop-tracking-mir.

On the change itself: I'd still prefer to be prudent about any divergence between the "trait" algorithm and the "storage" algorithm.
I understand that this PR emulates drop elaboration for the "trait" algorithm: if a local is moved-from on all paths that lead to a drop, then it does not need dropping.
Moving drop elaboration earlier has long been in the borrowck wishlist, but is hard enough to stay there long.

My proposal:

  • document that this attempts to emulate drop elaboration, a kind of implicit RemoveUninitDrops pass;
  • wait after Enable -Zdrop-tracking-mir by default #107421 merges;
  • run perf then to check we don't have a regression (MaybeInitializedLocals can be quite slow, as it tracks places, not just locals).

@bors
Copy link
Contributor

bors commented Sep 23, 2023

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

These tests are identical to the ones without drop-track prefix, so
remove.
@cjgillot
Copy link
Contributor

cjgillot commented Oct 4, 2023

I said I would run perf, and forgot.
@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Oct 4, 2023
@bors
Copy link
Contributor

bors commented Oct 4, 2023

⌛ Trying commit 0259c6e with merge 258decf...

bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 4, 2023
Stop considering moved-out locals when computing auto traits for generators

Addresses rust-lang#94067 (but does not fix it since drop-tracking-mir is unstable)

This PR, unlike rust-lang#110420 or rust-lang#112050, does not attempt to reduce the number of live locals across suspension points. It however ignores moved-out locals for trait purposes. So this PR solves the non-send issue, but not the size issue.

Suggested by `@RalfJung` in [rust-lang/unsafe-code-guidelines#188](rust-lang/unsafe-code-guidelines#188 (comment))

cc `@b-naber` who's working on this from a different perspective.

r? `@cjgillot`
@cjgillot
Copy link
Contributor

cjgillot commented Oct 4, 2023

One limitation of this PR is the interaction with drop-elaboration.
@RalfJung cited in #107421 (comment) an earlier adventure between drop elaboration and const checking.

  • I still have my concern about the auto-trait analysis and the layout analysis eventually drifting.

@bors
Copy link
Contributor

bors commented Oct 4, 2023

☀️ Try build successful - checks-actions
Build commit: 258decf (258decfeb5bf65897ee095291294f5800ad13f51)

@rust-timer

This comment has been minimized.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (258decf): comparison URL.

Overall result: ❌ regressions - ACTION NEEDED

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 may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.6% [0.4%, 0.8%] 5
Regressions ❌
(secondary)
3.0% [0.6%, 6.1%] 15
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) 0.6% [0.4%, 0.8%] 5

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.7% [2.8%, 6.4%] 7
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 623.925s -> 621.686s (-0.36%)
Artifact size: 272.03 MiB -> 272.00 MiB (-0.01%)

@rustbot rustbot added perf-regression Performance regression. and removed S-waiting-on-perf Status: Waiting on a perf run to be completed. labels Oct 5, 2023
@RalfJung
Copy link
Member

RalfJung commented Oct 5, 2023

One limitation of this PR is the interaction with drop-elaboration.

So this passes uses post-drop-elaboration MIR? Yeah that would be concerning.
Can it use pre-drop-elaboration MIR instead?

@cjgillot
Copy link
Contributor

cjgillot commented Oct 5, 2023

One limitation of this PR is the interaction with drop-elaboration.

So this passes uses post-drop-elaboration MIR? Yeah that would be concerning. Can it use pre-drop-elaboration MIR instead?

The current pass uses pre-drop-elaboration MIR. This PR proposes to elaborate some drops as part of the analysis.

I'm not fully aware of the difficulties around drop elaboration, so we need a bit of background on the foreseeable difficulties.

@cjgillot

This comment was marked as duplicate.

@apiraino
Copy link
Contributor

I think this might waiting on triaging the latest perf run

@rustbot author

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 21, 2023
@Dylan-DPC
Copy link
Member

@nbdd0121 any updates on this?

@Dylan-DPC
Copy link
Member

Closing this as inactive. Feel free to reöpen this pr or create a new pr if you get the time to work on this. Thanks

@Dylan-DPC Dylan-DPC closed this Jul 28, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 8, 2024
Stop considering moved-out locals when computing auto traits for generators (rebased)

This PR revives rust-lang#112279. I wanted to reopen this to gauge `@cjgillot's` thoughts about this, since it's been a while since `-Zdrop-tracking-mir` has landed.

If this PR looks OK, I can flesh it out and write up an FCP report -- I think this is a T-types FCP, since this has to do with the types that are considered live for auto traits, and doesn't otherwise affect the layout of coroutines.

Open questions:
* **"Why do we require storage to be live if the locals is not initialized?"** (rust-lang#112279 (comment))
    * I agree that we should eventually fix the storage analysis for coroutines, but this seems like a problem that can be fixed after we fix witnesses for *the purposes of traits* here.
    * As far as I could tell, fixing the problem of moved locals for *storage* would require insertion of additional `StorageDead` statements, or would require further entangling the type system with the operational semantics in ways that T-opsem seemed uncomfortable with [when I asked](https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Inserting.20.60StorageDrop.60.20after.20unconditional.20moves). cc `@RalfJung`
    * Relevant: rust-lang/unsafe-code-guidelines#188

Fixes rust-lang#128095
Fixes rust-lang#94067

r? `@cjgillot`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
perf-regression Performance regression. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants