incr. comp.: Increase partition granularity via special-casing non-inlined functions

[michaelwoerister]

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.

[michaelwoerister]

cc @nikomatsakis

[retep998]

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.

[michaelwoerister]

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.

[Mark-Simulacrum]

Has anything happened here? I don't think so, but perhaps an update would be good.

[michaelwoerister]

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.

[steveklabnik]

Triage: incremental compilation has come a long way, but I'm still not sure what the state is today.

[retep998]

Because codegen unit currently implies object file, this would make object file spam even worse of an issue, making #53014 occur far more often.