-
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
interpret: remove support for unsized_locals #98831
Conversation
Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
f1cc003
to
b007399
Compare
This comment has been minimized.
This comment has been minimized.
7356614
to
70fbc06
Compare
This comment was marked as resolved.
This comment was marked as resolved.
70fbc06
to
52625e2
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 52625e2cda587d5d4111a762e96c597f6a61a561 with merge 82ac962b53ec83a970c2f76fb4c21c590a27e6d5... |
☀️ Try build successful - checks-actions |
Queued 82ac962b53ec83a970c2f76fb4c21c590a27e6d5 with parent 9c9ae85, future comparison URL. |
Finished benchmarking commit (82ac962b53ec83a970c2f76fb4c21c590a27e6d5): 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. 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 |
r=me after a rebase |
Oh, bors never said there was a conflict, interesting... |
52625e2
to
6b927a5
Compare
@bors r=oli-obk |
📌 Commit 6b927a50903e3d4243480c968a7ddd68882d08dc has been approved by |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
Operand::Uninit is an *allocated* operand that is fully uninitialized. This lets us lazily allocate the actual backing store of *all* locals (no matter their ABI). I also reordered things in pop_stack_frame at the same time. I should probably have made that a separate commit...
6b927a5
to
dc9e0bf
Compare
@bors r=oli-obk |
📌 Commit dc9e0bf has been approved by |
☀️ Test successful - checks-actions |
adjust for removed unsized_locals The Miri side of rust-lang/rust#98831
adjust for removed unsized_locals The Miri side of rust-lang/rust#98831
adjust for removed unsized_locals The Miri side of rust-lang/rust#98831
Finished benchmarking commit (8824d13): 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 |
…oli-obk don't allow ZST in ScalarInt There are several indications that we should not ZST as a ScalarInt: - We had two ways to have ZST valtrees, either an empty `Branch` or a `Leaf` with a ZST in it. `ValTree::zst()` used the former, but the latter could possibly arise as well. - Likewise, the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`. - LLVM codegen already had to special-case ZST ScalarInt. So I propose we stop using ScalarInt to represent ZST (which are clearly not integers). Instead, we can add new ZST variants to those types that did not have other variants which could be used for this purpose. Based on rust-lang#98831. Only the commits starting from "don't allow ZST in ScalarInt" are new. r? `@oli-obk`
…oli-obk don't allow ZST in ScalarInt There are several indications that we should not ZST as a ScalarInt: - We had two ways to have ZST valtrees, either an empty `Branch` or a `Leaf` with a ZST in it. `ValTree::zst()` used the former, but the latter could possibly arise as well. - Likewise, the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`. - LLVM codegen already had to special-case ZST ScalarInt. So I propose we stop using ScalarInt to represent ZST (which are clearly not integers). Instead, we can add new ZST variants to those types that did not have other variants which could be used for this purpose. Based on rust-lang#98831. Only the commits starting from "don't allow ZST in ScalarInt" are new. r? `@oli-obk`
…i-obk don't allow ZST in ScalarInt There are several indications that we should not ZST as a ScalarInt: - We had two ways to have ZST valtrees, either an empty `Branch` or a `Leaf` with a ZST in it. `ValTree::zst()` used the former, but the latter could possibly arise as well. - Likewise, the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`. - LLVM codegen already had to special-case ZST ScalarInt. So I propose we stop using ScalarInt to represent ZST (which are clearly not integers). Instead, we can add new ZST variants to those types that did not have other variants which could be used for this purpose. Based on rust-lang#98831. Only the commits starting from "don't allow ZST in ScalarInt" are new. r? `@oli-obk`
…-obk Re-enable removal of ZST writes to unions This was previously disabled because Miri was lazily allocating unsized locals. But we aren't doing that anymore since rust-lang#98831, so we can have this optimization back.
Re-enable removal of ZST writes to unions This was previously disabled because Miri was lazily allocating unsized locals. But we aren't doing that anymore since rust-lang/rust#98831, so we can have this optimization back.
I added support for unsized_locals in #59780 but the current implementation is a crude hack and IMO definitely not the right way to have unsized locals in MIR. It also causes problems. and what codegen does is unsound and has been for years since clearly nobody cares (so I hope nobody actually relies on that implementation and I'll be happy if Miri ensures they do not). I think if we want to have unsized locals in Miri/MIR we should add them properly, either by having a
StorageLive
that takes metadata or by having analloca
that returns a pointer (making the ptr indirection explicit) or something like that.So, this PR removes the
LocalValue::Unallocated
hack. It addsImmediate::Uninit
, for several reasons:push_stack_frame
, in particular we do not actually have to create any allocations.ScalarMaybeUninit
, we will need something like this to have an "optimized" representation of uninitialized locals. Without this we'd have to put uninitialized integers into the heap!LocalValue::Unallocated
for that, now it can useImmediate::Uninit
.There is still a fundamental difference between
LocalValue::Unallocated
andImmediate::Uninit
: the latter is considered a regular local that you can read from and write to, it just has a more optimized representation when compared with an actualAllocation
that is fully uninit. In contrast,LocalValue::Unallocated
had this really odd behavior where you would write to it but not read from it. (This is in fact what caused the problems mentioned above.)While at it I also did two drive-by cleanups/improvements:
pop_stack_frame
, do the return value copying and local deallocation while the frame is still on the stack. This leads to better error locations being reported. The old errors were sometimes rather confusing.copy_op
andcopy_op_transmute
.r? @oli-obk