-
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
Refactor call terminator to always include destination place #96098
Conversation
Some changes occured to the CTFE / Miri engine cc @rust-lang/miri Some changes occured to rustc_codegen_cranelift cc @bjorn3 Some changes occurred in src/tools/clippy. cc @rust-lang/clippy |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 303e3a4388f8ef0df607abbd8f0d4b8fe23e3c27 with merge d584f7c49e7118da3500a697b2f6e3ba36f4af0a... |
☀️ Try build successful - checks-actions |
Queued d584f7c49e7118da3500a697b2f6e3ba36f4af0a with parent 3f391b8, future comparison URL. |
Finished benchmarking commit (d584f7c49e7118da3500a697b2f6e3ba36f4af0a): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking 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. @bors rollup=never Footnotes |
Small regression in const eval likely just llvm noise around the const eval logic, but please check by running the valgrind command from the link above |
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.
It is pretty straightforward-looking change.
/// Where the returned value will be written | ||
dest_place: Place<'tcx>, | ||
/// Where to go after this call returns. If none, the call necessarily diverges. | ||
dest_block: Option<BasicBlock>, |
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.
IMO there's little value in making this optional if the place isn’t. If the function call is guaranteed to not return, we can just codegen dest_block
into just an unreachable
. Arguably that will serve to homogenize semantics of MIR (and analysis) further.
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.
Hmm, I'm not sure. Intuitively, it feels like this information being accessible without having to go looking further might be valuable and simplify things. Maybe not though. I also don't know which version would be better for perf.
In any case, if we do consider such a change, I think we should make a uniform decision for this, TerminatorKind::SwitchInt
(which currently requires an otherwise block), and TerminatorKind::InlineAsm
(which does not require a destination/target block) on the basis of the needs of all three. That seems like too big/complicated of a conversation to have for this PR.
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.
agreed, let's try this in a follow up
extra, | ||
caller_abi, | ||
args, | ||
dest_block.map(|x| (dest_place, x)), |
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.
Looks like we should propagate this change through the machine interface all the way to Miri?
(Same for M::call_intrinsic
and M::find_mir_or_eval_fn
.)
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.
Yeah, I had avoided doing that for now because I'm not sure what the right procedure for it is. Should I just make the change and then send a follow-up PR to miri?
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.
Yes. It is okay for Miri to temporarily break in the rustc repo.
Ideally you can prepare the Miri PR already before this one lands, so that once this one lands we can get Miri fixed ASAP.
303e3a4
to
b3f5015
Compare
This comment has been minimized.
This comment has been minimized.
4f50b06
to
cd38f83
Compare
I only half know how to read these things, but nothing in the diff reported by cachegrind stands out: Diff
|
@rustbot ready |
☔ The latest upstream changes (presumably #96253) made this pull request unmergeable. Please resolve the merge conflicts. |
cd38f83
to
c58d924
Compare
This comment has been minimized.
This comment has been minimized.
⌛ Testing commit c8c64d3dbb7db11a37c9582f76bc68639543359a with merge 12da966580a170ebc534cf139395c0b9ba93baa5... |
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
c8c64d3
to
09b0936
Compare
Required a rebase to show up locally, trivial fix |
@bors r=oli-obk |
📌 Commit 09b0936 has been approved by |
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@43d9f38. Direct link to PR: <rust-lang/rust#96098> 💔 miri on windows: test-pass → build-fail (cc @eddyb @RalfJung @oli-obk). 💔 miri on linux: test-pass → build-fail (cc @eddyb @RalfJung @oli-obk).
Finished benchmarking commit (43d9f38): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
Adjust Miri to also require return places everywhere This is the miri side of rust-lang/rust#96098 . It'll still need a bump to rust-version once the rust PR is merged, but the test suite passes against my local build of rustc.
…-obk Refactor call terminator to always include destination place In rust-lang#71117 people seemed to agree that call terminators should always have a destination place, even if the call was guaranteed to diverge. This implements that. Unsurprisingly, the diff touches a lot of code, but thankfully I had to do almost nothing interesting. The only interesting thing came up in const prop, where the stack frame having no return place was also used to indicate that the layout could not be computed (or similar). I replaced this with a ZST allocation, which should continue to do the right things. cc `@RalfJung` `@eddyb` who were involved in the original conversation r? rust-lang/mir-opt
In #71117 people seemed to agree that call terminators should always have a destination place, even if the call was guaranteed to diverge. This implements that. Unsurprisingly, the diff touches a lot of code, but thankfully I had to do almost nothing interesting. The only interesting thing came up in const prop, where the stack frame having no return place was also used to indicate that the layout could not be computed (or similar). I replaced this with a ZST allocation, which should continue to do the right things.
cc @RalfJung @eddyb who were involved in the original conversation
r? rust-lang/mir-opt