rustc generates a lot of llvm ir for small programs due to inline generated drops

[jrmuizel]

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.

[jonas-schievink]

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]

But shouldn't those inline functions only be emitted if they are used by main.rs?

[RReverser]

@jrmuizel I think you need to use lto = true for final binary if you want such cross-crate optimizations (dead line code elimination, inlining etc.) to happen correctly.

[jrmuizel]

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]

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]

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]

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?

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]

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]

It seems like we could avoid having inline generated drop functions in debug builds though.

[jrmuizel]

It looks like the majority of the code is being added because of monomorphization caused by the inline drop.

[jrmuizel]

running RUST_LOG=rustc_trans rustc on 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]

This codegen test suggests that drop glue is not marked for inlining by default:
4ea25da#diff-d13eb81c7eec73d0e1f5f62e9c15e987b7fac6b90e1924401152d1146200b92fR1-R2

[jrmuizel]

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]

More specifically, for an example like:

struct A(String);

fn a(_: A) {}

becomes something like:

a(x: A) {
   core::ptr::drop_in_place::<A>(&x);
}

which even though it's not being inlined gets codegened in place because of monomorphization.