-
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
Stop considering moved-out locals when computing auto traits for generators #112279
Conversation
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
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 |
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.
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.
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.
That's currently an open question rust-lang/unsafe-code-guidelines#188 and is much harder to solve.
There is a meeting on july 24th to discuss soundness of |
☔ The latest upstream changes (presumably #88936) made this pull request unmergeable. Please resolve the merge conflicts. |
What's the outcome from the meeting? |
The meeting happened and decided to stabilize On the change itself: I'd still prefer to be prudent about any divergence between the "trait" algorithm and the "storage" algorithm. My proposal:
|
☔ 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.
I said I would run perf, and forgot. |
This comment has been minimized.
This comment has been minimized.
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`
One limitation of this PR is the interaction with drop-elaboration.
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
Finished benchmarking commit (258decf): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDBenchmarking 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 @bors rollup=never Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 623.925s -> 621.686s (-0.36%) |
So this passes uses post-drop-elaboration MIR? Yeah that would be concerning. |
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. |
This comment was marked as duplicate.
This comment was marked as duplicate.
I think this might waiting on triaging the latest perf run @rustbot author |
@nbdd0121 any updates on this? |
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 |
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`
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