-
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
Add a MIR pass manager (Taylor's Version) #91475
Conversation
r? @jackh726 (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
ec8cb0b
to
92e92db
Compare
cefefc4
to
37ac4ad
Compare
Looks like Generator drop shims already have `post_borrowck_cleanup` run on them. That's a bit surprising, since it means they're getting const- and maybe borrow-checked? This merits further investigation, but for now just preserve the status quo.
The noopt test never actually ran the pass
37ac4ad
to
7bc5eca
Compare
r? @oli-obk |
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 is really nice. It will make further changes so much easier to impl and reason about.
Also thx for the clean commits, reviewing was real easy.
r=me with ci passing, perf clean and the comment removed
// FIXME(#70073): This pass is responsible for both optimization as well as some lints. | ||
&const_prop::ConstProp, | ||
// | ||
// FIXME: The old pass manager ran this only at mir-opt-level >= 1, but |
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.
While const prop runs unconditionally, it doesn't change the MIR unless the opt level is 1 or above. So we indeed don't need to simplify unconditionally
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 7bc5eca with merge 0d6119ad550f626d8dac7253fa6d5897ec3d3667... |
☀️ Try build successful - checks-actions |
⌛ Testing commit 7bc5eca with merge 23fd1e950a1e0b895d1f1e5e0cc3f444c7ca21ce... |
💔 Test failed - checks-actions |
|
☀️ Test successful - checks-actions |
Finished benchmarking commit (bdaa901): comparison url. Summary: This change led to moderate relevant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
…anup, r=oli-obk Address some FIXMEs left over from rust-lang#91475 This shouldn't change behavior, only clarify what we're currently doing. I filed rust-lang#91576 to see if the treatment of generator drop shims is intentional. cc rust-lang#91475
…anup, r=oli-obk Address some FIXMEs left over from rust-lang#91475 This shouldn't change behavior, only clarify what we're currently doing. I filed rust-lang#91576 to see if the treatment of generator drop shims is intentional. cc rust-lang#91475
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#83744 (Deprecate crate_type and crate_name nested inside #![cfg_attr]) - rust-lang#90550 (Update certificates in some Ubuntu 16 images.) - rust-lang#91272 (Print a suggestion when comparing references to primitive types in `const fn`) - rust-lang#91467 (Emphasise that an OsStr[ing] is not necessarily a platform string) - rust-lang#91531 (Do not add `;` to expected tokens list when it's wrong) - rust-lang#91577 (Address some FIXMEs left over from rust-lang#91475) - rust-lang#91638 (Remove `in_band_lifetimes` from `rustc_mir_transform`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
The final draft of #91386 and #77665.
While the compile-time constraints in #91386 are cool, I decided on a more minimal approach for now. I want to explore phase constraints and maybe relative-ordering constraints in the future, though. This should preserve existing behavior exactly (please let me know if it doesn't) while making the following changes to the way we organize things today:
MirPhase
now corresponds to a single MIR pass.run_passes
is not responsible for listing the correct MIR phase.run_passes
no longer silently skips passes if the declared MIR phase is greater than or equal to the body's. This has bitten me multiple times. If you want this behavior, you can always branch onbody.phase
yourself.MirLint
interface instead, which gets a shared reference toBody
instead of a mutable one. By differentiating the two, I hope to make it clearer in the short term where lints belong in the pipeline. In the long term perhaps we could enforce this at compile-time?I tried to check that
-Zvalidate
still works correctly, since the MIR phase is now updated as soon as the associated pass is done, instead of at the end of all the passes inrun_passes
. However, it looks like-Zvalidate
is broken with current nightlies anyways 😢 (it spits out a bunch of errors).cc @oli-obk @wesleywiser
r? rust-lang/wg-mir-opt