Use a faster linker by default in the compiler profile

[Noratrieb]

By default for the compiler profile, we use the default system linker to compile the compiler. While this is the easiest solution that will work in the most cases, it's usually rather slow.

There is a rust.use-lld option in config.toml which can significantly speed up incremental builds and should be on by default.

This will work fine on Linux and should also work fine on Windows, but LLD on MacOS isn't well maintained and has issues so it should not be used by default. A better option here would be zld (there are two zlds out there, this is the right one). On Linux (and on MacOS once it's released), we may also be able to use mold, which is even faster and could make another difference.

[Noratrieb]

@rustbot label +A-bootstrap

[Noratrieb]

Note that on x86_64-unknown-linux-gnu (and other toolchains as well probably), the shipped rustc is linked with LLD already as can be seen with `readelf -p .comment ll (rustc +stable --print sysroot)/lib/librustc_driver*.

[chenyukang]

Have you tried to use mold to build Rust compiler,
What's the benchmark compared with default one?
I would like to have a try.

[chenyukang]

Seems there is a argument error for mold:

  = note: "/usr/local/bin/mold" "-m64" "/tmp/rustcQNhAzy/symbols.o"  ............
  = note: mold: fatal: unknown -m argument: 64

[SUPERCILEX]

cc @Kobzol You talked about using lld in your blog post, not sure if you've tried using mold too?

Also there's an existing issue about letting end users easily use mold: #94347

[Kobzol]

@SUPERCILEX This probably wasn't clear from the blog post, but I was talking about using lld to link rustc itself, not about using lld to link Rust programs compiled by rustc 😅 The latter should be much more useful for reducing compile times of Rust programs.

Nevermind, I didn't actually read what this issue is about, sorry :D The point below still stands though.

I don't think that it would be that useful to use mold to link rustc. It would probably not be trivial and the best we can hope to achieve with it is to reduce CI times slightly, but linking rustc isn't a bottleneck at the moment (at least on CI, the story might be different for rustc developers working on the compiler locally).

[SUPERCILEX]

Yeah, you're right I don't think mold does optimizations beyond what lld does so it probably wouldn't make a difference to end users.

[yshui]

Seems there is a argument error for mold:

  = note: "/usr/local/bin/mold" "-m64" "/tmp/rustcQNhAzy/symbols.o"  ............
  = note: mold: fatal: unknown -m argument: 64

rustc probably doesn't know how to drive mold yet, but -Clink-args=-fuse-ld=mold works.

[Kobzol]

On Linux, LLD is now the default on stages >= 1. For stage 0, LLD can help quite a lot for incremental rebuilds, but bootstrap currently doesn't support using the self-contained LLD linker. This means that if we switched the default, rustc would fail to compile unless you have a lld binary in PATH. So we should first fix the self-contained lld bootstrap option (I have it in my TODO list).

[Kobzol]

Self-contained LLD in bootstrap should now work fine, but it's also possible that the issue will resolve itself soon-ish on Linux (#140525) 😆