Uh oh!
There was an error while loading. Please reload this page.
Fix Dest Prop - #96451
Conversation
JakobDegen
commented
Apr 26, 2022
@bors try @rust-timer queue |
rust-timer
commented
Apr 26, 2022
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
bors
commented
Apr 26, 2022
⌛ Trying commit ac672ab9c0f14ea470820c5b9e1ac24d5cd3b536 with merge 86d0ce429f15243ad8abb713ac10f80134ca0832... |
JakobDegen
commented
Apr 26, 2022
Hmm, didn't hit that failure locally. Will try and debug tomorrow |
bors
commented
Apr 26, 2022
💔 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.
JakobDegen
commented
Apr 28, 2022
Agh. This might have to wait until next week, my laptop can't handle running tests and that might make things difficult |
JakobDegen
commented
Apr 29, 2022
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. |
oli-obk
commented
Apr 29, 2022
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 |
oli-obk
commented
Apr 29, 2022
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.
cjgillot
commented
Apr 29, 2022
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 |
JakobDegen
commented
Apr 30, 2022
Oh, wait, can try this again now... @bors try @rust-timer queue |
rust-timer
commented
Apr 30, 2022
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
bors
commented
Apr 30, 2022
⌛ Trying commit af83957d606cf4a6740b7cc30e7e29edb1746851 with merge 301aa4b1a05417c4803bbf04f9bbb4cbec740f61... |
rust-timer
commented
Oct 31, 2022
Queued 28afc0618fc643fded6958846b8f8a06d5ae81f4 with parent 4596f4f, future comparison URL. |
rust-timer
commented
Oct 31, 2022
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. |
JakobDegen
commented
Oct 31, 2022
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 |
bors
commented
Nov 15, 2022
☔ The latest upstream changes (presumably #101168) made this pull request unmergeable. Please resolve the merge conflicts. |
tmiasko
commented
Nov 15, 2022
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. |
bors
commented
Nov 15, 2022
✌️ @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.
JakobDegen
commented
Nov 27, 2022
@bors r=tmiasko |
bors
commented
Nov 27, 2022
bors
commented
Nov 27, 2022
bors
commented
Nov 27, 2022
☀️ Test successful - checks-actions |
rust-timer
commented
Nov 27, 2022
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
lbe the number of locals andsbe 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 ofMaybeLiveLocalsfor 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