- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
Add a MIR pass manager (Taylor's Version) #91475
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
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:
MirPhasenow corresponds to a single MIR pass.run_passesis not responsible for listing the correct MIR phase.run_passesno 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.phaseyourself.MirLintinterface instead, which gets a shared reference toBodyinstead 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
-Zvalidatestill 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-Zvalidateis broken with current nightlies anyways 😢 (it spits out a bunch of errors).cc @oli-obk @wesleywiser
r? rust-lang/wg-mir-opt