Skip to content
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

Eagerly collect mono items for non-generic closures #135314

Merged
merged 1 commit into from
Jan 11, 2025

Conversation

compiler-errors
Copy link
Member

This allows users to use -Zprint-mono-items=eager to eagerly monomorphize closures and coroutine bodies, in case they want to inspect the LLVM or ASM for those items.

-Zprint-mono-items, which used to be called -Zprint-trans-items, was originally added in #30900:

Eager mode is meant to be used in conjunction with incremental compilation
where a stable set of translation items is more important than a minimal
one. Thus, eager mode will instantiate drop-glue for every drop-able type
in the crate, even of no drop call for that type exists (yet). It will
also instantiate default implementations of trait methods, something that
otherwise is only done on demand.

Although it remains an unstable option, its purpose has somewhat expanded since then, and as far as I can tell it's generally useful for cases when you want to monomorphize as many items as possible, even if they're unreachable. Specifically, it's useful for debugging since you can look at the codegen'd body of a function, since we don't emit items that are not reachable in monomorphization.

And even more specifically, it would be very to monomorphize the coroutine body of an async fn, since those you can't easily call those without a runtime. This PR enables this usecase since we now monomorphize DefKind::Closure.

@rustbot
Copy link
Collaborator

rustbot commented Jan 10, 2025

r? @wesleywiser

rustbot has assigned @wesleywiser.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 10, 2025
Copy link
Member

@wesleywiser wesleywiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like -Clink-dead-code will enable eager collection as well but that seems entirely reasonable to me.

@wesleywiser
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jan 10, 2025

📌 Commit 6431504 has been approved by wesleywiser

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 10, 2025
@compiler-errors
Copy link
Member Author

Does it trigger eager collection of closures too?

@wesleywiser
Copy link
Member

I thought so since it triggers use of Eager mode and the collector doesn't seem to care about -Clink-dead-code specifically, it just changes behavior based on the collection mode

let collection_strategy = match tcx.sess.opts.unstable_opts.print_mono_items {
Some(ref s) => {
let mode = s.to_lowercase();
let mode = mode.trim();
if mode == "eager" {
MonoItemCollectionStrategy::Eager
} else {
if mode != "lazy" {
tcx.dcx().emit_warn(UnknownCguCollectionMode { mode });
}
MonoItemCollectionStrategy::Lazy
}
}
None => {
if tcx.sess.link_dead_code() {
MonoItemCollectionStrategy::Eager
} else {
MonoItemCollectionStrategy::Lazy
}
}
};
let (items, usage_map) = collector::collect_crate_mono_items(tcx, collection_strategy);

bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 11, 2025
…iaskrgr

Rollup of 4 pull requests

Successful merges:

 - rust-lang#134030 (add `-Zmin-function-alignment`)
 - rust-lang#134776 (Avoid ICE: Account for `for<'a>` types when checking for non-structural type in constant as pattern)
 - rust-lang#135205 (Rename `BitSet` to `DenseBitSet`)
 - rust-lang#135314 (Eagerly collect mono items for non-generic closures)

r? `@ghost`
`@rustbot` modify labels: rollup
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Jan 11, 2025
Rollup merge of rust-lang#135314 - compiler-errors:eagerly-mono-closures, r=wesleywiser

Eagerly collect mono items for non-generic closures

This allows users to use `-Zprint-mono-items=eager` to eagerly monomorphize closures and coroutine bodies, in case they want to inspect the LLVM or ASM for those items.

`-Zprint-mono-items`, which used to be called `-Zprint-trans-items`, was originally added in rust-lang#30900:

> Eager mode is meant to be used in conjunction with incremental compilation
> where a stable set of translation items is more important than a minimal
> one. Thus, eager mode will instantiate drop-glue for every drop-able type
> in the crate, even of no drop call for that type exists (yet). It will
> also instantiate default implementations of trait methods, something that
> otherwise is only done on demand.

Although it remains an unstable option, its purpose has somewhat expanded since then, and as far as I can tell it's generally useful for cases when you want to monomorphize as many items as possible, even if they're unreachable. Specifically, it's useful for debugging since you can look at the codegen'd body of a function, since we don't emit items that are not reachable in monomorphization.

And even more specifically, it would be very to monomorphize the coroutine body of an async fn, since those you can't easily call those without a runtime. This PR enables this usecase since we now monomorphize `DefKind::Closure`.
@bors bors merged commit 076c047 into rust-lang:master Jan 11, 2025
6 checks passed
@rustbot rustbot added this to the 1.86.0 milestone Jan 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants