-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Don't run various MIR optimizations at mir-opt-level=0 #70073
Conversation
@bors r+ |
📌 Commit d158587eb76428d060bb08170813e8b9ada881aa has been approved by |
@bors r- |
d158587
to
349f193
Compare
src/librustc_mir/transform/mod.rs
Outdated
// Deaggregation isn't technically an optimization but it unlocks opportunities | ||
// for later optimization passes. | ||
&deaggregator::Deaggregator, |
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.
But then why is it not run earlier?
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.
I don't know but I think the only passes that would be affected by this are CopyPropagation
and SimplifyLocals
which both run after this one.
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.
@eddyb said "people just probably didn't care much about it and added passes before and after".
So I'd vote for moving it up to the other lowering passes.
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.
I recall someone mentioning that drop elaboration relies on aggregates still being intact, and the generator transform performs drop elaboration. Not very sure though.
349f193
to
6f341f7
Compare
This comment has been minimized.
This comment has been minimized.
@wesleywiser you have conflicts to resolve |
I can resolve them but we're really waiting on some feedback from @oli-obk 🙂 |
6f341f7
to
9ec3e06
Compare
@bors retry |
⌛ Testing commit f4dfb99 with merge fadd2a48ae5148f9181745a3956dee1523d291c5... |
💔 Test failed - checks-azure |
Network failure. @bors retry |
☀️ Test successful - checks-azure |
…chievink smoke-test for async fn with mir-opt-level=0 MIR opt levels heavily influence which MIR transformations run, and we barely test non-default opt levels. I am particularly worried about `async fn` lowering and how it might (not) work when the set of preceding MIR passes changes -- see rust-lang#70073. This adds some basic smoke testing, where at least a few `async fn` `run-pass` test are ensured to also work with mir-opt-level=0.
…leywiser move Deaggregate pass to post_borrowck_cleanup Reopen of rust-lang#71946 Only the second commit is from this PR, the other commit is a bugfix that's in the process of getting merged. I'll rebase once that's done In rust-lang#70073 MIR pass handling got reorganized, but with the goal of not changing behavior (except for disabling some optimizations on opt-level = 0). But there we realized that the Deaggregator pass, while conceptually more of a "cleanup" pass (and one that should be run before optimizations), was run in the middle of the optimization chain. Likely this is an accident of history, so I suggest we try and clean that up by making it a proper cleanup pass. This does change mir-opt output, because deaggregation now runs before const-prop instead of after. r? @wesleywiser @rust-lang/wg-mir-opt cc @RalfJung
Add missing checks for mir-opt-level to non-essential MIR passes.
I verified that this can still bootstrap even with these passes disabled.
r? @oli-obk cc @RalfJung