Description
Proposal
Within the Rust compiler there are a number of places that we need to generate "anonymous" constants - for example, string literals that are directly used without being stored in a constant or the caller location information for panic! macros.
These are generated by the ConstMethods traits, which are implemented in compiler/rustc_codegen_llvm/src/common.rs for LLVM.
Within this implementation we use internal linkage for strings and private linkage for allocations, which instructs LLVM that each of these items should be kept by the linker, even if they share a name or contents with other items across translation units (i.e., crates). This results in common constants being duplicated across crates, for example the panic messages from Option::unwrap and Result::unwrap.
My proposal is to instruct LLVM that these can be folded by making the following changes in both const_str and in scalar_to_backend (for Scalar::Ptr pointing to GlobalAlloc::Memory with a mutability of Mutability::Not):
- Always generate a name based on the hash of the contents (regardless of the
fewer_namesoption). - Use
WeakODRLinkage(i.e., only keep one, contents much match else fail to link). - Set a COMDAT based on the name.
- Emit a global value debug symbol with the name (to allow binary analysis tools like SizeBench to be able to attribute the binary size to a compiler feature and allow diffing binaries).
These changes can be seen at rust-lang/rust#114816
It's likely that this change will regress compiler performance, but projects that utilize a lot of crates should see a decent binary size win (for example, rustc_driver had a 3.5% size reduction for me locally (141,846kb to 136,762kb on x86_64-pc-windows-msvc built as release with assertions enabled).
Mentors or Reviewers
Process
The main points of the Major Change Process are as follows:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
Comments
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.