Consider building libstd with codegen-units=1 for release artifacts

[michaelwoerister]

The main reason I'd like to have this is because it would allow fat-LTO'ed staticlibs to be used as input for LLD-based ThinLTO (which is something that Firefox might want to do, if it brings performance wins). It might also improve runtime performance of all Rust programs without incurring as much of a CI cycle time penalty as building everything with -Ccodegen-units=1 would.

cc @rust-lang/release

[Mark-Simulacrum]

To clarify, this is just std? Or would we want std and its dependencies? It does seem plausible that std being built in this fashion would fit into the window of time we have, cc @alexcrichton @rust-lang/infra

[michaelwoerister]

To clarify, this is just std?

Everything from libcore to libstd.

[alexcrichton]

I agree that this has a possibility of making some release-mode Rust programs faster by default as well (as std itself will get more inlining opportunities), although I suspect the number of programs there that get faster is quite small in that almost all perf-sensitive funcitons in libstd are already monomorphized/inlined. I agree though that the amount of time it takes on CI to build libstd/libcore with one CGU should be pretty minimal.

@michaelwoerister I don't understand though what you mention is the original motivation for this issue? If you fat-LTO all Rust code together into a staticlib that doesn't matter how many CGUs each of the input crates has, right? It should be compatible with libstd having any number of CGUs, and we'd just need to make sure that the staticlib output is compatible with LLD-based ThinLTO

[michaelwoerister]

@alexcrichton The problem is just that we run into a form of #53912 with a ThinLTO'd libstd because some symbols in there have gone through the ThinLTO mangling before LLD does it a second time. The problem could also be solved by doing some kind of fix-up pass on the IR before emitting it into the staticlib.

[alexcrichton]

Ah ok, makes sense!

We've already got a smattering of weird patches of "randomly patching LLVM IR" to avoid bugs in LLVM so shouldn't be too hard to add another!

[michaelwoerister]

Yes, such a pass will probably be the more stable option in the long run.