-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Fix inlining with -Zalways-encode-mir #115194
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
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
28e0353
to
8bc7d3e
Compare
r? compiler |
8bc7d3e
to
4cfd237
Compare
// Reachability pass defines which functions are eligible for inlining. Generally inlining | ||
// other functions is incorrect, because they could reference symbols that aren't exported. |
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 change is coupling the MIR inliner even more to our dubious reachability analysis, and I think that's the wrong way to improve things.
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.
How does it increase coupling to reachability analysis?
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.
MIR inlining needs to agree with the logic used to generate MIR for items and also with whether statics are considered reachable. If it doesn't, we end up needing MIR for a function that we don't have, or we end up requiring visibility for a static that was previously determined to be internal.
This change as written currently is restricting MIR inlining to match the behavior of this function:
fn item_might_be_inlined(tcx: TyCtxt<'_>, item: &hir::Item<'_>, attrs: &CodegenFnAttrs) -> bool { |
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.
Yes, of course it needs to agree with definition in reachability pass. It was also the case before, so I am quite confused by your comment about increased coupling.
Only inline functions that are considered eligible for inlining by the reachability pass. This constraint was previously indirectly enforced by only exporting MIR of eligible functions, but that approach doesn't work with -Zalways-encode-mir enabled.
4cfd237
to
fe3cd2d
Compare
Yeah, the coupling was always there. @bors r+ |
945cde2
to
fe3cd2d
Compare
Ups, pushed to a wrong branch. @bors r=compiler-errors |
☀️ Test successful - checks-actions |
Finished benchmarking commit (b1b244d): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 633.863s -> 631.655s (-0.35%) |
Only inline functions that are considered eligible for inlining
by the reachability pass.
This constraint was previously indirectly enforced by only exporting MIR
of eligible functions, but that approach doesn't work with
-Zalways-encode-mir enabled.