-
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
Replace MemoryExtra by Memory in intptrcast methods #62003
Conversation
Can you change |
Also, please prepare a Miri PR that fixes compiling Miri with these changes. It should not do anything else, so we can land it quickly once this one here lands. |
Sure, I'll do the change in rustc and then do the respective miri PR |
@bors r+ |
📌 Commit e152c38 has been approved by |
☀️ Test successful - checks-travis, status-appveyor |
Tested on commit rust-lang/rust@56a12b2. Direct link to PR: <rust-lang/rust#62003> 💔 miri on windows: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra). 💔 miri on linux: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
@rust-lang/infra no issue was created... did I screw up in #61938 ? |
The logs seem reasonable?
|
Oh yes, I did screw up... And with Python's scoping rules, |
Hm no, that log is created by a totally different script, at https://github.com/rust-lang/rust/blob/56a12b2ad058f22f1ef090713df15598525ba4a4/src/ci/docker/x86_64-gnu-tools/checkregression.py, called at
|
(Continuing at #62023.) |
publish_toolstate: don't use 'new' from inside the loop I think I made a mistake in rust-lang#61938 by using `new` outside the inner loop. This PR fixes that. However, no issue got created at all for rust-lang#62003 (comment), and I don't know why that is. The script should be [triggered by Traivs](https://github.com/rust-lang/rust/blob/56a12b2ad058f22f1ef090713df15598525ba4a4/.travis.yml#L240), and I can find no trace of that in [the build log](https://travis-ci.com/rust-lang/rust/jobs/209880042).
publish_toolstate: don't use 'new' from inside the loop I think I made a mistake in rust-lang#61938 by using `new` outside the inner loop. This PR fixes that. However, no issue got created at all for rust-lang#62003 (comment), and I don't know why that is. The script should be [triggered by Traivs](https://github.com/rust-lang/rust/blob/56a12b2ad058f22f1ef090713df15598525ba4a4/.travis.yml#L240), and I can find no trace of that in [the build log](https://travis-ci.com/rust-lang/rust/jobs/209880042).
publish_toolstate: don't use 'new' from inside the loop I think I made a mistake in rust-lang#61938 by using `new` outside the inner loop. This PR fixes that. However, no issue got created at all for rust-lang#62003 (comment), and I don't know why that is. The script should be [triggered by Traivs](https://github.com/rust-lang/rust/blob/56a12b2ad058f22f1ef090713df15598525ba4a4/.travis.yml#L240), and I can find no trace of that in [the build log](https://travis-ci.com/rust-lang/rust/jobs/209880042).
publish_toolstate: don't use 'new' from inside the loop I think I made a mistake in rust-lang#61938 by using `new` outside the inner loop. This PR fixes that. However, no issue got created at all for rust-lang#62003 (comment), and I don't know why that is. The script should be [triggered by Traivs](https://github.com/rust-lang/rust/blob/56a12b2ad058f22f1ef090713df15598525ba4a4/.travis.yml#L240), and I can find no trace of that in [the build log](https://travis-ci.com/rust-lang/rust/jobs/209880042).
This caused a perf regression. Is that expected? Could the regression be avoided? |
No that's not expected. In fact it seems really strange because the only instance of all of these methods that's used in rustc is basically doing nothing. Maybe the default instances need to be marked |
[WIP] Debug perf regression from Miri Machine trait changes Maybe this fixes the perf regression that #62003 seemingly introduced? Cc @nnethercote
@@ -416,11 +416,11 @@ impl<'mir, 'tcx, M: Machine<'mir, 'tcx>> Memory<'mir, 'tcx, M> { | |||
id: AllocId, | |||
) -> InterpResult<'tcx, &mut Allocation<M::PointerTag, M::AllocExtra>> { | |||
let tcx = self.tcx; | |||
let memory_extra = &self.extra; | |||
let alloc = Self::get_static_alloc(id, tcx, &self); |
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.
Oh, I had entirely missed this! This is not what we want. This is the reason for the perf regression. We don't want to ask for a static alloc if we don't absolutely need it. You turned the vast majority of the get_mut
calls from one to two HashMap
lookups.
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 could also explain why MIRI_BACKTRACE=1
made everything so awfully slow when I used it for debugging on CI.
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.
Oh I remember that change, that was because there was no way to pass self
into the get_mut_or
without having a mutable and an immutable reference at the same time.
Before doing the MemoryExtra -> Memory
change, we passed just self.extra
and get_mut_or
was called from self.alloc_map
so there was no borrowing issues.
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, that's why I am reverting to just MemoryExtra
now.
Next time you have to reorder code like that in a way that moves an operation out of a closure and makes it executed much more often than previously... please call that out when submitting the PR, so we can review that specifically. :) I should have seen this in the review, but it gets easier when you call out the "most interesting" bits.
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 sorry, that was a little careless from my part. Next time will do
Edit: I assume we could modify how get_mut_or
works or adding a get_mut
but I don't think it is worth it
Fix perf regression from Miri Machine trait changes Maybe this fixes the perf regression that #62003 seemingly introduced? Cc @nnethercote
Fix perf regression from Miri Machine trait changes Maybe this fixes the perf regression that rust-lang#62003 seemingly introduced? Cc @nnethercote
Fix perf regression from Miri Machine trait changes Maybe this fixes the perf regression that rust-lang#62003 seemingly introduced? Cc @nnethercote
r? @RalfJung @oli-obk