Remove -Zinline-in-all-cgus · Issue #814 · rust-lang/compiler-team (original) (raw)
Proposal
The flag -Zinline-in-all-cgus was added in rust-lang/rust#45075. I think before that PR, #[inline] caused what we today call LocalCopy codegen to occur at any optimization level. In the current compiler, we only do LocalCopy codegen when optimizations are enabled. -Zinline-in-all-cgus=no -Copt-level={1,2,3} will produce an optimized build where #[inline] functions get the LLVM inlinehint attribute, but still get GloballyShared codegen. -Zinline-in-all-cgus=yes -Copt-level=0 will produce an unoptimized build where #[inline] functions still get LocalCopy codegen, but the LLVM inliner isn't run so the extra copies are useless. I think both scenarios where the flag has any effect are undesirable, and the only useful behavior is the compiler's behavior when the flag is not used.
I believe the flag was added as a just-in-case way to opt back into the previous behavior and provide users additional control over codegen. But based on some GitHub code search, there are literally no users of this flag on GitHub, and the one commented-out use that I could find was a user trying to add -Zinline-in-all-cgus=yes to -Copt-level=3 to get more optimizations.
We should delete the flag because it has no value. I dislike how it complicates instantiation mode selection and is used so heavily in the codegen-units test suite, which has caused me a lot of grief trying to improve instantiation mode selection on real code and also keep the tests passing. Removing this flag would make our tests look more like real-world use of the compiler.
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.