-
Notifications
You must be signed in to change notification settings - Fork 69
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
Add Rvalue::ShallowInitBox
to MIR
#460
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed. cc @rust-lang/compiler @rust-lang/compiler-contributors |
Seems like the correct way to move this forward. @rustbot second |
TerminatorKind::Box
to MIRRvalue::ShallowInitBox
to MIR
@rustbot label -final-comment-period +major-change-accepted |
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.
Introduce `Rvalue::ShallowInitBox` 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 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 #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.
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 #89030 and MCP rust-lang/compiler-team#460. ~1 month later nothing seems to be broken, apart from a small regression that #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 #89030 and MCP rust-lang/compiler-team#460. ~1 month later nothing seems to be broken, apart from a small regression that #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
Proposal
Introduce a new
Rvalue
variant,Rvalue::ShallowInitBox
. It accepts an operand and a type, and will convert the operand to a shallowly-initialized box. This design is considered the better approach than aBox
terminator after the Zulip dicussion.In today's the MIR,
box expr
is translated to:however this does not allow unwind. Unwinding is necessary for rust-lang/rfcs#2116's
oom=panic
support (tracked in rust-lang/rust#43596).Under this proposal, the originally
Rvalue::NullaryOp(NullOp::Box, ty)
is split into two operations, first a call toexchange_malloc(size_of::<ty>(), align_of::<ty>())
, then converts it into a shallow-initialized box:with the extra unwinding edge provided by the
exchange_malloc
call.The operational behaviour of
ShallowInitBox
is simply transmuting*mut u8
toBox<T>
. The only thing special is that dataflow analysis will treat the content of the box as uninitialized.An alternative is to remove
box_syntax
andBox
nullary op from MIR at all; however, an attempt in rust-lang/rust#87781 shows very significant regression when doing so (perf run). Here is an godbolt snippet shows a case wherebox
still needs special treatment in the MIR, and thusbox_syntax
is still needed at least as an implementation detail of the library.Another alternative is the original proposal, to add a
TerminatorKind::Box
. However adding a new terminator requires much more changes than the current proposal.The original proposal
Introduce a new terminator,
TerminatorKind::Box
to the MIR of form:it'll be roughly equivalent to
in today's MIR, but has an additional unwind edge.
Box
needs to be a special terminator rather than a function call, because a function call will deep-initialize the return place whileBox
will only shallow-initialize its return place.The overall plan is:
TerminatorKind::Box
Box
terminator vsBox
nullary opbox_syntax
to useBox
terminator instead ofBox
nullary opBox
as a nullary op.Mentors or Reviewers
If you have a reviewer or mentor in mind for this work, mention then
here. You can put your own name here if you are planning to mentor the
work.
Process
The main points of the Major Change Process are as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
The text was updated successfully, but these errors were encountered: