-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-MIRArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlA-mir-opt-inliningArea: MIR inliningArea: MIR inliningC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.I-slowIssue: Problems and improvements with respect to performance of generated code.Issue: Problems and improvements with respect to performance of generated code.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
It is very common to clutter libraries with #[inline]
annotations on small/trivial functions to ensure that they optimize well. It shouldn't really be necessary to do this by hand so often. Instead, the compiler could use its inlining heuristic (which already exists for the MIR inliner) to decide when it is likely to be beneficial to make a function inlineable.
This was previously attempted in #70550
jyn514, bugadani, Aaron1011, tgnottingham, mbartlett21 and 10 more
Metadata
Metadata
Assignees
Labels
A-MIRArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlArea: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.htmlA-mir-opt-inliningArea: MIR inliningArea: MIR inliningC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.I-slowIssue: Problems and improvements with respect to performance of generated code.Issue: Problems and improvements with respect to performance of generated code.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.