Add -Z dead-fn-elimination to skip codegen of BFS-unreachable functions

[yijunyu]

MCP: Add -Z dead-fn-elimination to skip codegen of BFS-unreachable functions

Proposal

Add an unstable -Z dead-fn-elimination flag that performs BFS reachability from binary entry points over the MIR call graph, then excludes unreachable functions from codegen via an is_codegened_item query override. ~462 lines across 6 files.

Large binary crates spend significant LLVM time on functions the linker later discards via --gc-sections. This flag moves that elimination before LLVM, at the MIR level. On a patched stage2 compiler, zed builds 8% faster and rustc builds 6% faster; smaller projects break even. The algorithm has been validated as an external RUSTC_WRAPPER tool (cargo-slicer).

An 12-point safety checklist ensures only private, non-generic, non-async, safe, non-Drop standalone functions are eliminated. Generic functions, async functions, unsafe functions, vtable-dispatched methods, #[no_mangle]/#[used] items, and functions whose signatures involve fn() pointers or dyn Trait are unconditionally kept. This MCP also provides foundational BFS infrastructure for a broader crate slicing project goal (a separate proposal).

Detailed design, benchmarks, and the full safety proof: docs/upstream-rfc.md

Mentors or Reviewers

Community feedback incorporated from @lcnr, @Amanieu, @workingjubilee, @oli-obk.

Note

Concerns (0 active)

• relation-with-project-goal resolved in this comment

Managed by @rustbot—see help for details.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

[apiraino]

@rustbot concern relation-with-project-goal

Is this the same of the (not accepted) project goal https://github.com/rust-lang/rust-project-goals/blob/main/src/2026/crate-slicing.md (discussed on Zulip).

[yijunyu]

No it is not the same as the original project goal. This MCP has a narrower aim, instead of doing both intra-crate and inter-crate analysis, it focuses on the intra-crate one so that one does not need to resort to an external helper utility to figure out the symbols of other crates. This being said, the benefit might be smaller. The major advantage of having it done inside the compiler, rather than in an external rustc_driver, is to be able to remove the reliance on a specific nightly release of the rustc, and has the potential to be stabilised later. I hope the external inter-crate analysis could still be done on top of this MCP later so we won't lose any benefit in the end.

[apiraino]

@yijunyu thanks for clarifying, just please don't forget to discuss the proposal on Zulip, otherwise some comments could be overlooked (see comment).

@rustbot resolve relation-with-project-goal

[yijunyu]

Yes I clarified on the goal page that it is not going to be Medium effort once the MCP is done. Also I have checked the conference policy that the paper under review could be put on the arxiv.org after a couple of weeks, which will document the solution to the goal more clearly.