incr. comp.: Increase partition granularity via special-casing non-inlined functions
If we put every function into its own codegen unit, we would minimize the amount of functions being re-translated even though they have not changed. The main reason we don't do this, is because it would completely prevent inlining, which in turn has too detrimental an effect on runtime performance.
However, for many functions we could probably predict very well that they would never get inlined by LLVM anyway, because they are marked with #[inline(never)] or they are just too big. This category of functions could be put into their own codegen unit without negative effects on runtime performance.
cc @nikomatsakis
Michael Woerister at 2016-08-22 19:37:14
Even if a function is marked with
#[inline(never)]that doesn't mean it won't inline other functions into it. Wouldn't having it in a codegen unit of its own would prevent it from inlining other functions in the same crate.Peter Atashian at 2016-08-22 20:21:13
Having it in a codegen unit of its own would prevent it from inlining other functions in the same crate.
Not necessarily. It could still inline as many functions as it wants (via copying those functions into the codegen unit of its "main" functions). That just leads to another kind of false positives when it comes to recompilation.
Michael Woerister at 2016-08-22 20:25:50
Has anything happened here? I don't think so, but perhaps an update would be good.
Mark Rousskov at 2017-05-12 00:17:02
Well, generic functions are not treated as inline functions by default anymore. Otherwise the status is the same. ThinLTO might open up some interesting opportunities here, since it potentially decouples runtime performance from CGU granularity.
Michael Woerister at 2017-05-12 09:58:31
Triage: incremental compilation has come a long way, but I'm still not sure what the state is today.
Steve Klabnik at 2018-09-24 15:56:28
Because codegen unit currently implies object file, this would make object file spam even worse of an issue, making https://github.com/rust-lang/rust/issues/53014 occur far more often.
Peter Atashian at 2018-09-24 17:52:10