-
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
Fix Dest Prop #96451
Fix Dest Prop #96451
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit ac672ab9c0f14ea470820c5b9e1ac24d5cd3b536 with merge 86d0ce429f15243ad8abb713ac10f80134ca0832... |
Hmm, didn't hit that failure locally. Will try and debug tomorrow |
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Agh. This might have to wait until next week, my laptop can't handle running tests and that might make things difficult |
I actually did get a chance to take a look at this, and I think what's going on is this: The test failure was not indicative of a bug, but rather was "expected" in that dest prop eliminated the local whose mutability changed, and so now the optimized MIR no longer differed between the revisions. I confirmed by looking at the Fixing this by turning off optimizations seems like a principled approach, since "optimized MIR differs due to a trivial change in the source code" does not seem like something we actually want to be true. |
but... without optimizations this is now true afaict? You could leave optimizations on and remove the dirty flag for |
Eh, yeah, when I say "optimized MIR" I mean "optimized MIR with optimizations on." Removing the dirty flag is also an option, but doesn't that test less? After all, ensuring that the relevant revision causes changes in MIR if we don't optimize still seems like something we want |
yea... there's merit for both... 🤷 let's do yours for now, it's more representative of what we had |
This comment has been minimized.
This comment has been minimized.
Removing the dirty flag in the incremental test is the right thing to do here. This allows to track the evolution of the incremental behaviour. (And actually, the less "dirty" flags there are in those files, the better). |
Hmm, ok. Will change that next time I push |
Oh, wait, can try this again now... @bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit af83957d606cf4a6740b7cc30e7e29edb1746851 with merge 301aa4b1a05417c4803bbf04f9bbb4cbec740f61... |
Queued 28afc0618fc643fded6958846b8f8a06d5ae81f4 with parent 4596f4f, future comparison URL. |
Finished benchmarking commit (28afc0618fc643fded6958846b8f8a06d5ae81f4): comparison URL. Overall result: no relevant changes - no action neededBenchmarking 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 Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. |
I can comment the pass out for now if you want to, I did measure non-negligible impact in some cases once this is turned on though |
3685ce7
to
98c884a
Compare
☔ The latest upstream changes (presumably #101168) made this pull request unmergeable. Please resolve the merge conflicts. |
Removing unused local declarations immediately after dead store elimination sounds good. Just wanted to check the potential compile time impact of pull request in the form it would actually land. r=me when rebased. |
✌️ @JakobDegen can now approve this pull request |
This fixes a number of correctness issues from the previous version. Additionally, we use a new strategy which has much better performance charactersitics and also finds more opportunities to apply the optimization.
98c884a
to
245c607
Compare
@bors r=tmiasko |
☀️ Test successful - checks-actions |
Finished benchmarking commit (0e9eee6): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
Closes #82678, #79191 .
This was not originally a total re-write of the pass but is has gradually turned into one. Notable changes:
Regarding Performance
The previous approach had some performance issues; letting
l
be the number of locals ands
be the number of statements/terminators, the runtime of the pass wasO(l^2 * s)
, both in theory and in practice. This version is smarter about not calculating unnecessary things and doing more caching. Our runtime is now dominated by one invocation ofMaybeLiveLocals
for each "round," and the number of rounds is less than 5 in over 90% of cases. This means it's linear-ish in practice.r? @oli-obk who reviewed the last version of this, but review from anyone else would be more than welcome