record fewer adjustment types in generator witnesses, avoid spurious drops in MIR construction #64584
Conversation
That's way more than is needed, and winds up recording types that will never appear in MIR.
rust-highfive
added
the
S-waiting-on-review
| // traits always return references, which means their content | ||
| // can be reborrowed without needing to spill to a temporary. | ||
| // If this were not the case, then we could conceivably have | ||
| // to create intermediate temporaries.) |
Should probably check how this performs, but it's always nicer to track just a bit less mutable state.
Currently, after a CALL terminator is created in MIR, we insert DROP statements for all of its operands -- even though they were just moved shortly before! These spurious drops are later removed, but not before causing borrow check errors. This PR series modifies the drop code to track operands that were moved and avoid creating drops for them. Right now, I'm only using this mechanism for calls, but it seems likely it could be used in more places.
nikomatsakis
force-pushed
the
issue-64477-generator-capture-types
branch
from
f15278f
to
b2c51c2
Compare
|
Hmm, so this PR seems fairly urgent -- @eddyb, do you think you'd be able to review? |
|
Mostly I want to land these fixes to avoid problems for async-await. |
|
r? @eddyb |
This comment has been minimized.
This comment has been minimized.
|
welp apparently I broke the test for #40883 somehow (we use more stack now). Not quite sure why that would be. Comparing the MIR between nightly and my branch, it looks basically the same, but I must be missing something. Edit: > diff mir_dump/rustc.supersize_me.003-026.PreCodegen.after.mir mir_dump.1/rustc.supersize_me.003-026.PreCodegen.after.mirhuh. Also, when I build and run by hand, I don't see the problem. Hmm. |
|
OK, I think I found the mistake. I didn't intend to screen out |
nikomatsakis
changed the title
|
So locally I get debuginfo test failures when running this branch, but I am wondering if that is some kind of environmental fail on my end -- I'm hard pressed to imagine how my changes here are causing them, and when I run gdb by hand everything seems to work fine. |
|
@bors r=eddyb p=1 |
|
📌 Commit 77fd0a7 has been approved by |
bors
added
S-waiting-on-bors
…es, r=eddyb record fewer adjustment types in generator witnesses, avoid spurious drops in MIR construction Don't record all intermediate adjustment types -- That's way more than is needed, and winds up recording types that will never appear in MIR. Note: I'm like 90% sure that this logic is correct, but this stuff is subtle and can be hard to keep straight. However, the risk of this PR is fairly low -- if we miss types here, I believe the most common outcome is an ICE. This fixes the original issue cited by #64477, but I'm leaving the issue open for now since there may be other cases we can detect and improve in a targeted way. r? @Zoxc
|
☀️ Test successful - checks-azure |
|
Either this PR or #64498 caused a major regression in rustc perf. It's hard to tell because the graph goes up on #64498 , then down for a single run, then stabilizes again at the worse performance after this PR. I suggest backing out both PRs, opening new PRs, and then doing perf runs on both. That should make it clear which one cause the regression. cc @rust-lang/compiler |
|
Ah, this might be premature- we recently landed self-profile work on perf which is 95% certainty the cause of the regression, I plan on trying to eliminate those overheads from reported stats in the coming week. |
Don't record all intermediate adjustment types -- That's way more than is needed, and winds up recording types that will never appear in MIR.
Note: I'm like 90% sure that this logic is correct, but this stuff is subtle and can be hard to keep straight. However, the risk of this PR is fairly low -- if we miss types here, I believe the most common outcome is an ICE.
This fixes the original issue cited by #64477, but I'm leaving the issue open for now since there may be other cases we can detect and improve in a targeted way.
r? @Zoxc