Stop storing a special inner body for the coroutine by-move body for async closures#128506
Stop storing a special inner body for the coroutine by-move body for async closures#128506bors merged 2 commits intorust-lang:masterfrom
Conversation
|
r? @chenyukang rustbot has assigned @chenyukang. Use |
|
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
This comment was marked as outdated.
This comment was marked as outdated.
|
Anywhomst, cc @RalfJung if you're curious about what this ended up looking like. |
| } | ||
| } | ||
|
|
||
| // Enforce that coroutine-closure layouts are identical. |
There was a problem hiding this comment.
We stopped caring about this since #123021.
|
Let's get perf kicked off. I'll fix the codegen tests when I get home. @bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
Stop storing a special inner body for the coroutine by-move body for async closures ...and instead, just synthesize an item which is treated mostly normally by the MIR pipeline. This PR does a few things: * We synthesize a new `DefId` for the by-move body of a closure, which has its `mir_built` fed with the output of the `ByMoveBody` MIR transformation, and some other relevant queries. * Remove the special `PassManager` hacks for handling the inner `by_move_body` stored within the coroutine's mir body. Instead, this body is fed like a regular MIR body, so it's goes through all of the `tcx.*_mir` stages normally (build -> promoted -> ...etc... -> optimized) ✨. * Introduce `TyCtxt::is_synthetic_mir` to skip over `mir_borrowck` which is called by `mir_promoted`; borrowck isn't really possible to make work ATM since it heavily relies being called on a body generated from HIR, and is redundant by the construction of the by-move-body. * Remove the `InstanceKind::ByMoveBody` shim, since now we have a "regular" def id, we can just use `InstanceKind::Item`. This also allows us to remove the corresponding hacks from codegen, such as in `fn_sig_for_fn_abi` ✨. Notable remarks: * I know it's kind of weird to be using `DefKind::Closure` here, since it's not a distinct closure but just a new MIR body. I don't believe it really matters, but I could also use a different `DefKind`... maybe one that we could use for synthetic MIR bodies in general?
This comment has been minimized.
This comment has been minimized.
|
☀️ Try build successful - checks-actions |
This comment has been minimized.
This comment has been minimized.
36ed446 to
776dc68
Compare
|
Finished benchmarking commit (3904d97): 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)Results (primary 5.4%, secondary 8.5%)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.
CyclesResults (primary 1.7%)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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 756.054s -> 761.062s (0.66%) |
|
If this doesn't help things, I'll investigate adding a new |
|
@bors try @rust-timer queue |
This comment has been minimized.
This comment has been minimized.
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
|
windows should stop being a supported operating system tbh @bors retry |
…llot Stop storing a special inner body for the coroutine by-move body for async closures ...and instead, just synthesize an item which is treated mostly normally by the MIR pipeline. This PR does a few things: * We synthesize a new `DefId` for the by-move body of a closure, which has its `mir_built` fed with the output of the `ByMoveBody` MIR transformation, and some other relevant queries. * This has the `DefKind::ByMoveBody`, which we use to distinguish it from "real" bodies (that come from HIR) which need to be borrowck'd. Introduce `TyCtxt::is_synthetic_mir` to skip over `mir_borrowck` which is called by `mir_promoted`; borrowck isn't really possible to make work ATM since it heavily relies being called on a body generated from HIR, and is redundant by the construction of the by-move-body. * Remove the special `PassManager` hacks for handling the inner `by_move_body` stored within the coroutine's mir body. Instead, this body is fed like a regular MIR body, so it's goes through all of the `tcx.*_mir` stages normally (build -> promoted -> ...etc... -> optimized) ✨. * Remove the `InstanceKind::ByMoveBody` shim, since now we have a "regular" def id, we can just use `InstanceKind::Item`. This also allows us to remove the corresponding hacks from codegen, such as in `fn_sig_for_fn_abi` ✨. Notable remarks: * ~~I know it's kind of weird to be using `DefKind::Closure` here, since it's not a distinct closure but just a new MIR body. I don't believe it really matters, but I could also use a different `DefKind`... maybe one that we could use for synthetic MIR bodies in general?~~ edit: We're doing this now.
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
|
@bors retry |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (d9a2cc4): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression 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. CyclesResults (primary 2.2%, secondary 2.5%)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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 752.135s -> 754.016s (0.25%) |
…idtwco Do not call query to compute coroutine layout for synthetic body of async closure There is code in the MIR validator that attempts to prevent query cycles when inlining a coroutine into itself, and will use the coroutine layout directly from the body when it detects that's the same coroutine as the one that's being validated. After rust-lang#128506, this logic didn't take into account the fact that the coroutine def id will differ if it's the "by-move body" of an async closure. This PR implements that. Fixes rust-lang#129811
...and instead, just synthesize an item which is treated mostly normally by the MIR pipeline.
This PR does a few things:
DefIdfor the by-move body of a closure, which has itsmir_builtfed with the output of theByMoveBodyMIR transformation, and some other relevant queries.DefKind::ByMoveBodyDefKind::SyntheticCoroutineBody, which we use to distinguish it from "real" bodies (that come from HIR) which need to be borrowck'd. IntroduceTyCtxt::is_synthetic_mirto skip overmir_borrowckwhich is called bymir_promoted; borrowck isn't really possible to make work ATM since it heavily relies being called on a body generated from HIR, and is redundant by the construction of the by-move-body.PassManagerhacks for handling the innerby_move_bodystored within the coroutine's mir body. Instead, this body is fed like a regular MIR body, so it's goes through all of thetcx.*_mirstages normally (build -> promoted -> ...etc... -> optimized) ✨.InstanceKind::ByMoveBodyshim, since now we have a "regular" def id, we can just useInstanceKind::Item. This also allows us to remove the corresponding hacks from codegen, such as infn_sig_for_fn_abi✨.Notable remarks:
I know it's kind of weird to be usingedit: We're doing this now.DefKind::Closurehere, since it's not a distinct closure but just a new MIR body. I don't believe it really matters, but I could also use a differentDefKind... maybe one that we could use for synthetic MIR bodies in general?