-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 new Deinit
statement
#95125
Add new Deinit
statement
#95125
Conversation
Some changes occured to the CTFE / Miri engine cc @rust-lang/miri |
This comment has been minimized.
This comment has been minimized.
33a366c
to
e1dc823
Compare
This comment has been minimized.
This comment has been minimized.
e1dc823
to
7236347
Compare
Bot doesn't pick it up, so cc @bjorn3 for the cranelift change and... probably someone for clippy, but not sure |
This comment has been minimized.
This comment has been minimized.
cg_clif changes looks fine to me. |
@bors try @rust-timer queue Will review next week, let's see what perf says 'till then |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 7236347a2324c8d571138f81dafd8b150f17eb5b with merge a920b8a92d5e86353acdc0c28bbcaa945ce3b565... |
☀️ Try build successful - checks-actions |
Queued a920b8a92d5e86353acdc0c28bbcaa945ce3b565 with parent 499d4a5, future comparison URL. |
Finished benchmarking commit (a920b8a92d5e86353acdc0c28bbcaa945ce3b565): comparison url. Summary: This benchmark run did not return any relevant results. 7 results were found to be statistically significant but too small to be relevant. 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 led to changes in compiler perf. @bors rollup=never |
This seems to be a tiny slowdown overall. |
Yeah, that might be the result of an additional variant on |
7236347
to
ac33542
Compare
The new commits include most of the changes that were also made in #94590 . The only outstanding concern there was Nagisa bringing up that an issue should be opened for the disabled tests - I can do that once either PR merges |
dcf356c
to
338c80a
Compare
I had meant to add the validator checks but forgot about it - also addressed the other two concerns |
9681a02
to
48b01a0
Compare
@bors r+ rollup=never |
📌 Commit 2f03767 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (625e4dd): comparison url. Summary:
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 Footnotes |
A small perf regression is to be expected here I think. MIR contains more statements now, and even though we don't codegen the new ones, we still have to process them in rustc. The cost of this could definitely be reduced by optimizations as Oli already mentioned, but I don't think this particular case is any more interesting than all the other examples of optimizations we could do but don't yet. |
I ran cachegrind on some of the regressions, adn all of them seem to be in metadata de/serialization except for cranelift, which looks like LLVM noise. Considering that this is groundwork for fixing bugs in our dataflow analyses, which directly impact MIR opt sounness, I think we have to take this hit @rustbot label: +perf-regression-triaged |
|
||
/// Mark the entire referenced range as uninitalized | ||
pub fn write_uninit(&mut self) { | ||
self.alloc.mark_init(self.range, false); |
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.
Uh-oh, making mark_init
public was a mistake. (Not sure when that happened, that was before this PR.)
This call is wrong, since it forgets to also clear the relocations in that range. Some other uses of mark_init
are also wrong. I am working on a fix.
(To be clear, this is not your fault. We did bad API design here.)
We codegen an assignment to non-det value per documentation. See more information here: - rust-lang/rust#95125
We codegen an assignment to non-det value per documentation. See more information here: - rust-lang/rust#95125
* Update rust toolchain to nightly-2022-05-03 This compiles but regression is failing due to unimplemented statement. * Handle change to Box<T> structure Box<T> now users NonNull<T> instead of raw pointer. * Handle new statement kind Deinit We codegen an assignment to non-det value per documentation. See more information here: - rust-lang/rust#95125 * Fix discriminant computation After the merge, the previous wrapping sub logic was triggering a panic due to u128 -> i64 conversion. There were also other overflow issues when trying to convert the `niche_value` to unsigned. For now, I'm disabling the coversion check which I believe is too strict. We should consider implementing a more flexible check later that can be controlled by the user without affecting the internal compiler codegen. * Address PR comments: - Improve comments. - Remove wrong cast to i64. - Fix statement location. - Create util function to create unsigned type.
This rvalue replaces
SetDiscriminant
for ADTs. This PR is an alternative to #94590 , which only specifies that the behavior ofSetDiscriminant
is the same as what this rvalue would do. The motivation for this change are discussed in that PR and on Zulipr? @oli-obk