Stream: t-compiler/wg-pipelining

Topic: Linker pipelining

Alex Crichton (Sep 05 2019 at 02:39, on Zulip):

One thing I talked with others at rustconf a bit is splitting out a linker step from rustc, and while motivated by a bunch of other things it's also pretty relevant to pipelining. Often the final crate can be one of the biggest (think build scripts, procedural macros, binaries, etc), but we currently can't pipeline them at all. If Cargo could, however, split out the linker step, we would be able to pipeline everything.

Imagine, for example, that instead of rustc --tons --of --flags Cargo instead executed:

$ rustc --do-not-link --tons --of --flags
$ rustc --do-only-link --tons --of --flags

If we had a scheme like that then --do-not-link would be a pipelineable compilation (it only needs the rmeta from upstream crates) and --do-only-link would have to wait for everything to fully finish. This would be a relatively large-ish change to the compiler but perhaps not the worst thing in the world. Ideally --do-only-link would be very fast since it would forcibly skip all of typechecking and such. Ideally --do-not-link would emit something like a *.rlib but perhaps call it a *.rlink which has all the intermediate information for --do-only-link to immediately resume at the linking phase.

I think this would allow us to get 100% of the benefit from pipelining architecturally (other than making rmeta generation cheaper and further forward in compilation). This would also have lots of cascading effects on other strategies which want to separate the linker. This would be a relatively big feature for the compiler, though, so it probably wants both experimentation and an RFC to accompany it. Wanted to make sure I wrote down the thoughts though!

Alex Crichton (Sep 05 2019 at 20:17, on Zulip):

I've opened an issue for this topic

Last update: Apr 06 2020 at 02:25UTC