-
Notifications
You must be signed in to change notification settings - Fork 13.3k
[WIP] Implement a "place unification" MIR optimization (aka source/destination propagation aka NRVO). #47954
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
@bors try |
⌛ Trying commit f88212c with merge 7a4d4c6c9a94179431514d0494125a3339f25718... |
💔 Test failed - status-travis |
|
@bors try |
[WIP] Implement a "place unification" MIR optimization (aka source/destination propagation). *nothing to see here* (PR open for testing purposes) note to self: **DO NOT MERGE** without inspecting all `FIXME` / `HACK` comments
💔 Test failed - status-travis |
Looks like banning |
☔ The latest upstream changes (presumably #47962) made this pull request unmergeable. Please resolve the merge conflicts. |
👁 We See All 👁 Like the fact that triage notices this has been open for a week, has some CI failures, and some merge conflicts. Any hopes of fixing those issues in the near future? |
@shepmaster I can close while I'm not using this (I just need to remember to reopen before pushing). |
aee57ce
to
44afedf
Compare
@bors try |
[WIP] Implement a "place unification" MIR optimization (aka source/destination propagation). *nothing to see here* (PR open for testing purposes) note to self: **DO NOT MERGE** without inspecting all `FIXME` / `HACK` comments
💔 Test failed - status-travis |
☔ The latest upstream changes (presumably #47926) made this pull request unmergeable. Please resolve the merge conflicts. |
☀️ Test successful - status-travis |
Perf started. |
Latest perf results look much better, worse regression is |
Ping from triage! Do you still need this @eddyb? |
I'm going to go ahead and close this -- @eddyb feel free to re-open. I'm assuming we don't want to merge? (Title is WIP..) |
@eddyb Have you made any progress with this? |
@MSxDOS I may have found a way to make this cheap enough to always run it. |
Any updates? |
Closing this due to inactivity |
Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by @eddyb in rust-lang#47954, and then explored by me in rust-lang#71003, and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default, some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress`, which caused trouble in my last attempt, but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher, if it is too slow to run in debug mode, but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine, or if not, merge the variable's live ranges (or remove these statements entirely – rust-lang#68622). Some benchmarks of the pass were done in rust-lang#72635.
Implement a generic Destination Propagation optimization on MIR This takes the work that was originally started by `@eddyb` in rust-lang#47954, and then explored by me in rust-lang#71003, and implements it in a general (ie. not limited to acyclic CFGs) and dataflow-driven way (so that no additional infrastructure in rustc is needed). The pass is configured to run at `mir-opt-level=2` and higher only. To enable it by default, some followup work on it is still needed: * Performance needs to be evaluated. I did some light optimization work and tested against `tuple-stress`, which caused trouble in my last attempt, but didn't go much in depth here. * We can also enable the pass only at `opt-level=2` and higher, if it is too slow to run in debug mode, but fine when optimizations run anyways. * Debuginfo needs to be fixed after locals are merged. I did not look into what is required for this. * Live ranges of locals (aka `StorageLive` and `StorageDead`) are currently deleted. We either need to decide that this is fine, or if not, merge the variable's live ranges (or remove these statements entirely – rust-lang#68622). Some benchmarks of the pass were done in rust-lang#72635.
nothing to see here (PR open for testing purposes)
note to self: DO NOT MERGE without inspecting all
FIXME
/HACK
comments