Uh oh!
There was an error while loading. Please reload this page.
Split dead store elimination off dest prop - #97158
Conversation
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
tmiasko
commented
May 19, 2022
@bors try @rust-timer queue |
rust-timer
commented
May 19, 2022
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
bors
commented
May 19, 2022
⌛ Trying commit e54b7e0a6573ca8eb8a308363449835b27647cbd with merge edc0389da8df533107b33d6dba3ef7021209ede0... |
bors
commented
May 19, 2022
☀️ Try build successful - checks-actions |
rust-timer
commented
May 19, 2022
Queued edc0389da8df533107b33d6dba3ef7021209ede0 with parent 67a9bcb, future comparison URL. |
rust-timer
commented
May 19, 2022
Finished benchmarking commit (edc0389da8df533107b33d6dba3ef7021209ede0): 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. Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @bors rollup=never Footnotes |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
JakobDegen
commented
May 21, 2022
The update should address all the outstanding review comments. I've also added in a check that ensure we don't optimize out ptr2int casts. Once CI passes, I'll restart perf as well |
JakobDegen
commented
May 21, 2022
@bors try @rust-timer queue @rustbot ready Oh also, I still need to add some actual tests. Kind of forgot to do that because of all the existing MIR opt tests this affects |
rust-timer
commented
May 21, 2022
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
bors
commented
May 21, 2022
⌛ Trying commit e17fcacd7035e80d6ceab06aee48da58a675c9e1 with merge ee288a61fe1e3c195eeadd3527ccf09eddf63506... |
bors
commented
May 21, 2022
☀️ Try build successful - checks-actions |
rust-timer
commented
May 21, 2022
Queued ee288a61fe1e3c195eeadd3527ccf09eddf63506 with parent e6a4afc, future comparison URL. |
JakobDegen
commented
May 25, 2022
Interesting. The test failed because bors turns off optimizations for tests. I've asked T-Infra on Zulip, also cc @cjgillot who answered questions about these tests last time I had one and may want to weigh in |
cjgillot
commented
May 25, 2022
The simplest way would be to force either optimization or no-optimization on those tests. |
JakobDegen
commented
May 25, 2022
For all incremental tests or just for those? |
cjgillot
commented
May 25, 2022
All those in the |
JakobDegen
commented
May 28, 2022
@cjgillot done. There were two files ( |
cjgillot
commented
May 28, 2022
@bors r=tmiasko,cjgillot |
bors
commented
May 28, 2022
📌 Commit 7a99da1 has been approved by |
bors
commented
May 28, 2022
bors
commented
May 28, 2022
☀️ Test successful - checks-actions |
Tested on commit rust-lang/rust@6831417. Direct link to PR: <rust-lang/rust#97158> 💔 miri on windows: test-pass → test-fail (cc @oli-obk@eddyb@RalfJung). 💔 miri on linux: test-pass → test-fail (cc @oli-obk@eddyb@RalfJung).
rust-timer
commented
May 28, 2022
Finished benchmarking commit (6831417): 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. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
JakobDegen
commented
May 29, 2022
For perf triage: In non-opt builds, things generally improved which means we are optimizing quite some things that LLVM doesn't catch. The only regressions are in bitmaps and some wg-grammar stuff. I checked with cachegrind, it points to For opt builds, some things slowed down. This is to be expected to some extent, since rustc is optimizing things it wasn't before and so doing more work. I ran cachegrind on a couple of the slower benchmarks and nothing stood out to me. The serde full one is reproduced below if anyone else wants to take a look. Likely the only way to improve upon the regressions is to make this pass faster. That is certainly desirable, but I don't know of any low hanging fruit there. Serde Full CachegrindIn any case, this 1) is a performance improvement in most cases, 2) is a de-facto prerequisite for dest prop, and 3) causes the compiler to emit faster object code, so I generally think the regressions are justified. Meta sidenote: What are the rules around applying the "perf-regression-triaged" label? If I am investigating compiler perf anyway, should I also be applying the label or is this something that should be reserved for wg-perf/people with r+ rights? |
Uh oh!
There was an error while loading. Please reload this page.
pnkfelix
commented
May 31, 2022
@rustbot label: +perf-regression-triaged |
This splits off a part of #96451 . I've added this in as its own pass for now, so that it actually runs, can be tested, etc. In the dest prop PR, I'll stop invoking this as its own pass, so that it doesn't get invoked twice.
r? @tmiasko