Experiment with sharing monomorphized code between crates

[michaelwoerister]

At the moment the compiler will re-instantiate generic code in every crate that uses it. That sounds like a lot of duplicated work. However, we don't have any actual numbers on how much duplicated work. There are a few things we could do:

• Instrument the compiler to count how many duplicated functions we have
• Prototype sharing of generic code and see how it affects compile times and binary sizes
• Wait for MIR-only RLIBs to solve the problem naturally.

This could potentially be a big win for compile times but we won't know until we've collected some data.

Side node: Sharing monomorphized instances could negatively affect runtime performance when compiling without any form of LTO or when compiling with ThinLTO just for the current crate (as opposed to doing ThinLTO over the whole crate graph).

[brson]

#47660 indicates a check box next to this task, but it is still open and doesn't indicate progress. Is this done?

[michaelwoerister]

This has been implemented in #48779 and is enabled by default for optimization levels <= 2:

rust/src/librustc/session/config.rs

Lines 650 to 664 in f694222

	pub fn share_generics(&self) -> bool {
	match self.debugging_opts.share_generics {
	Some(setting) => setting,
	None => {
	match self.optimize {
	OptLevel::No |
	OptLevel::Less |
	OptLevel::Size |
	OptLevel::SizeMin => true,
	OptLevel::Default |
	OptLevel::Aggressive => false,
	}
	}
	}
	}

#50861 tested enabling it for optimized builds showed mixed results:
https://perf.rust-lang.org/compare.html?start=fd18d2537ddcffb24b3739393b085ed28dfc340e&end=b60bd5703773a04cd853519fdc2465dc9d45603d&stat=instructions%3Au

[brson]

Thanks @michaelwoerister