-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Introduce Rvalue::ShallowInitBox
#89030
Conversation
Some changes occured to rustc_codegen_cranelift cc @bjorn3 Some changes occurred in src/tools/clippy. cc @rust-lang/clippy Some changes occured to the CTFE / Miri engine cc @rust-lang/miri |
(rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
Fix missing `no_global_oom_handling` cfg-gating Cfg-gate these trait impls that are neglected. These functions compile now because they use `box` syntax which depends on `exchange_malloc` during codegen only; as a result they compiles with cfg `no_global_oom_handling` but shouldn't. Discovered in rust-lang#89030 because that PR makes `box` syntax depend on `exchange_malloc` lang item during MIR construction.
r? @jonas-schievink, who seconded the MCP. I don't know enough about MIR to review this PR. |
Fix missing `no_global_oom_handling` cfg-gating Cfg-gate these trait impls that are neglected. These functions compile now because they use `box` syntax which depends on `exchange_malloc` during codegen only; as a result they compiles with cfg `no_global_oom_handling` but shouldn't. Discovered in rust-lang#89030 because that PR makes `box` syntax depend on `exchange_malloc` lang item during MIR construction.
This comment has been minimized.
This comment has been minimized.
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.
Changes look generally good to me! A few notes:
- This comment can now be removed
- Is
NullOp::Box
still used anywhere or can/should it be removed?
substs: tcx.mk_substs_trait(ty, &[]), | ||
}; | ||
|
||
self.prove_trait_ref( |
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.
I guess this is copied from NullaryOp
(can the branches be merged?), but I don't get why this is both doing ensure_place_sized
and proving that ty: Sized
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.
@@ -2450,6 +2456,10 @@ impl<'tcx> Debug for Rvalue<'tcx> { | |||
}), | |||
} | |||
} | |||
|
|||
ShallowInitBox(ref place, ref ty) => { | |||
write!(fmt, "ShallowInitBox({:?}, {:?})", place, ty) |
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.
This looks a bit odd in the MIR dumps (with a value and a type being passed the same way), but it does match how NullaryOp
is printed, so I guess this can be improved later on.
No, it won't be used anymore. My thought is that if we keep it, it'll be easier to revert if anything goes wrong. Reverting "Use Rvalue::ShallowInitBox for box expression" would be enough to bring back the old code path. If you feel that it should be removed in this PR, I can do that as well. |
This comment has been minimized.
This comment has been minimized.
Seems reasonable! @bors r+ rollup=never (for the perf triage team: there's a slight perf impact expected, which was previously measured in #88700 (comment)) |
📌 Commit ab64580 has been approved by |
Looks like a bogus failure. |
@bors retry |
☀️ Test successful - checks-actions |
Finished benchmarking commit (e9f29a8): comparison url. Summary: This change led to large relevant regressions 😿 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
@nbdd0121 @jonas-schievink I see there was a bit of a justification for the perf regression given when opening this PR:
The perf regressions aren't huge but I wouldn't classify themselves as small either. We have some non-noisy, real world crate test cases that are showing regressions that are 9 times larger than the calculated significance threshold. This isn't nearly big enough to merit a revert, but if there's a clear path forward for trying to gain the performance back it's probably worth trying to do that sooner rather than later (considering this is for a feature flagged feature and doesn't really benefit any users at this point). Thoughts? |
The wall-clock time of some of these "regressions" are improved though; instruction count isn't the full picture. |
Introduce `Rvalue::ShallowInitBox` Polished version of rust-lang#88700. Implements MCP rust-lang/compiler-team#460, and should allow rust-lang#43596 to go forward. In short, creating an empty box is split from a nullary-op `NullOp::Box` into two steps, first a call to `exchange_malloc`, then a `Rvalue::ShallowInitBox` which transmutes `*mut u8` to a shallow-initialized `Box<T>`. This allows the `exchange_malloc` call to unwind. Details can be found in the MCP. `NullOp::Box` is not yet removed, purely to make reverting easier in case anything goes wrong as the result of this PR. If revert is needed a reversion of "Use Rvalue::ShallowInitBox for box expression" commit followed by a test bless should be sufficient. Experiments in rust-lang#88700 showed a very slight compile-time perf regression due to (supposedly) slightly more time spent in LLVM. We could omit unwind edge generation (in non-`oom=panic` case) in box expression MIR construction to restore perf; but I don't think it's necessary since runtime perf isn't affected and perf difference is rather small.
@nbdd0121 wall-clock time is an extremely noisy metric which we don't usually look at unless the gains are consistent and large which is not the case here. Of course, instruction count is only part of the picture, but it's generally the best we have for determining runtime performance changes, so I still think discussing the targeted fixed is warranted. |
Remove `NullOp::Box` Follow up of rust-lang#89030 and MCP rust-lang/compiler-team#460. ~1 month later nothing seems to be broken, apart from a small regression that rust-lang#89332 (1aac85bb716c09304b313d69d30d74fe7e8e1a8e) shows could be regained by remvoing the diverging path, so it shall be safe to continue and remove `NullOp::Box` completely. r? `@jonas-schievink` `@rustbot` label T-compiler
Remove `NullOp::Box` Follow up of rust-lang#89030 and MCP rust-lang/compiler-team#460. ~1 month later nothing seems to be broken, apart from a small regression that rust-lang#89332 (1aac85bb716c09304b313d69d30d74fe7e8e1a8e) shows could be regained by remvoing the diverging path, so it shall be safe to continue and remove `NullOp::Box` completely. r? `@jonas-schievink` `@rustbot` label T-compiler
Remove `NullOp::Box` Follow up of rust-lang#89030 and MCP rust-lang/compiler-team#460. ~1 month later nothing seems to be broken, apart from a small regression that rust-lang#89332 (1aac85bb716c09304b313d69d30d74fe7e8e1a8e) shows could be regained by remvoing the diverging path, so it shall be safe to continue and remove `NullOp::Box` completely. r? `@jonas-schievink` `@rustbot` label T-compiler
Polished version of #88700.
Implements MCP rust-lang/compiler-team#460, and should allow #43596 to go forward.
In short, creating an empty box is split from a nullary-op
NullOp::Box
into two steps, first a call toexchange_malloc
, then aRvalue::ShallowInitBox
which transmutes*mut u8
to a shallow-initializedBox<T>
. This allows theexchange_malloc
call to unwind. Details can be found in the MCP.NullOp::Box
is not yet removed, purely to make reverting easier in case anything goes wrong as the result of this PR. If revert is needed a reversion of "Use Rvalue::ShallowInitBox for box expression" commit followed by a test bless should be sufficient.Experiments in #88700 showed a very slight compile-time perf regression due to (supposedly) slightly more time spent in LLVM. We could omit unwind edge generation (in non-
oom=panic
case) in box expression MIR construction to restore perf; but I don't think it's necessary since runtime perf isn't affected and perf difference is rather small.