Repository navigation
rustc generates a lot of llvm ir for small programs due to inline generated drops #38827
Description
Building https://github.com/jrmuizel/webrender/blob/sample-min/sample-min/src/main.rs ends up generating 12MB of LLVM IR (25MB of LLVM IR with debug info turned on). This seems like an excessive amount and it has a big impact on build times.
Activity
jonas-schievink commentedon Jan 4, 2017
webrender marks a lot of functions as
#[inline]for performance, which causes their IR to be included in your crate.#[inline]has always been problematic for build times.jrmuizel commentedon Jan 4, 2017
But shouldn't those inline functions only be emitted if they are used by main.rs?
RReverser commentedon Jan 4, 2017
@jrmuizel I think you need to use
lto = truefor final binary if you want such cross-crate optimizations (dead line code elimination, inlining etc.) to happen correctly.jrmuizel commentedon Jan 4, 2017
I'm not really looking for cross-crate optimizations so lto seems inappropriate.
Why do we need to re-emit the ir for unused inline functions? How could these functions ever be used?
jonas-schievink commentedon Jan 4, 2017
They are used by the functions used by main.rs. All inline-functions transitively used by your code will be included in the crate's LLVM module IIRC. This gives LLVM the ability to inline all of them (if it decides to do so) into your code.
jrmuizel commentedon Jan 5, 2017
So it looks like the bulk of this code is from the drop function implementations. i.e. mem::forgetting the return values from renderer::Renderer::new(opts) and compiling with -C panic=abort drops the IR size to 1.3MB. Is there a reason the drop functions need to be inline?
RReverser commentedon Jan 5, 2017
Well, you're looking for dead code elimination (not emitting functions from other crate that are unused), so you do want cross-crate optimization.
bluss commentedon Jan 5, 2017
One reason is that automatically generated drop (like for Renderer) can not be marked inline explicitly, so it would limit programs to not have them inlineable by default.
jrmuizel commentedon Jan 5, 2017
It seems like we could avoid having inline generated drop functions in debug builds though.
[-]rustc generates a lot of llvm ir for small programs[/-][+]rustc generates a lot of llvm ir for small programs due to inline generated drops[/+]jrmuizel commentedon Apr 5, 2017
It looks like the majority of the code is being added because of monomorphization caused by the inline drop.
jrmuizel commentedon Jul 11, 2017
running
RUST_LOG=rustc_trans rustcon this example shows 4614 functions being translated. I wonder if it would be pursuing polymorphic code gen so that we don't get hammered with monomorphization.scottmcm commentedon Feb 23, 2022
This codegen test suggests that drop glue is not marked for inlining by default:
4ea25da#diff-d13eb81c7eec73d0e1f5f62e9c15e987b7fac6b90e1924401152d1146200b92fR1-R2
jrmuizel commentedon Feb 23, 2022
Indeed. As I understand it, the problem is not that code is marked as inline it's that it's generic code that gets a monomorphized version generated for it instead of sharing it. See #68414 and #84175
jrmuizel commentedon May 15, 2022
More specifically, for an example like:
becomes something like:
which even though it's not being inlined gets codegened in place because of monomorphization.