Use lld with non-LLVM backends #132774
Use lld with non-LLVM backends #132774
Conversation
rustbot
added
S-waiting-on-review
Again, this is just when no flavor/self-contained-linking is specified. r? lqd |
|
I guess I should say "by default". Let me update the commit message. |
|
There should be no reason CI would fail, but r=me when it's green. |
On arm64, Cranelift used to produce object files that don't work with lld. This has since been fixed. The GCC backend should always produce object files that work with lld unless lld for whatever reason drops GCC support. Most of the other more niche backends don't use cg_ssa's linker code at all. If they do and don't work with lld, they can always disable lld usage using a cli argument. Without this commit using cg_clif is by default in a non-trivial amount of cases a perf regression on Linux due to ld.bfd being a fair bit slower than lld. It is possible to explicitly enable it without this commit, but most users are unlikely to do this.
|
@bors r=lqd |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#132341 (Reject raw lifetime followed by `'`, like regular lifetimes do) - rust-lang#132363 (Enforce that raw lifetimes must be valid raw identifiers) - rust-lang#132744 (add regression test for rust-lang#90781) - rust-lang#132754 (Simplify the internal API for declaring command-line options) - rust-lang#132772 (use `download-rustc="if-unchanged"` as a global default) - rust-lang#132774 (Use lld with non-LLVM backends) - rust-lang#132799 (Make `Ty::primitive_symbol` recognize `str`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#132774 - bjorn3:cranelift_lld, r=lqd Use lld with non-LLVM backends On arm64, Cranelift used to produce object files that don't work with lld. This has since been fixed. The GCC backend should always produce object files that work with lld unless lld for whatever reason drops GCC support. Most of the other more niche backends don't use cg_ssa's linker code at all. If they do and don't work with lld, they can always disable lld usage using a cli argument. Without this commit using cg_clif is by default in a non-trivial amount of cases a perf regression on Linux due to ld.bfd being a fair bit slower than lld. It is possible to explicitly enable it without this commit, but most users are unlikely to do this.
Use lld with non-LLVM backends On arm64, Cranelift used to produce object files that don't work with lld. This has since been fixed. The GCC backend should always produce object files that work with lld unless lld for whatever reason drops GCC support. Most of the other more niche backends don't use cg_ssa's linker code at all. If they do and don't work with lld, they can always disable lld usage using a cli argument. Without this commit using cg_clif is by default in a non-trivial amount of cases a perf regression on Linux due to ld.bfd being a fair bit slower than lld. It is possible to explicitly enable it without this commit, but most users are unlikely to do this.
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#132341 (Reject raw lifetime followed by `'`, like regular lifetimes do) - rust-lang#132363 (Enforce that raw lifetimes must be valid raw identifiers) - rust-lang#132744 (add regression test for rust-lang#90781) - rust-lang#132754 (Simplify the internal API for declaring command-line options) - rust-lang#132772 (use `download-rustc="if-unchanged"` as a global default) - rust-lang#132774 (Use lld with non-LLVM backends) - rust-lang#132799 (Make `Ty::primitive_symbol` recognize `str`) r? `@ghost` `@rustbot` modify labels: rollup
This comment may not be completely accurate. @antoyo has been asking me weird obscure questions about lld for some reason for a few weeks now, as well as on zulip -- and I've only now realized that this PR of course initiated his issues, so I've referred him to your expertise @bjorn3. I guess it may be interesting to only allow |
|
I did be fine with disabling lld for cg_gcc specifically and any other backend after they found issues until the root cause of those issues is found. I prefer not using an allowlist for using lld however as that will only delay discovery of lld related issues and when mixing multiple codegen backends it is still possible that lld gets used even if a backend isn't on the allowlist. Same with the end user adding |
|
@bjorn3: For context, my last (hopefully) issue is that LTO doesn't work.
|
|
Ah, right. Lld only supports LLVM LTO. Unless you use |
Yeah, I was thinking about that: this must be what I'm doing wrong. Does that mean that |
|
Yes, the path should be ignored with lld. |
|
I was able to fix all the issues (well, I muted one for now 😄 ), so I guess we can keep |
On arm64, Cranelift used to produce object files that don't work with lld. This has since been fixed. The GCC backend should always produce object files that work with lld unless lld for whatever reason drops GCC support. Most of the other more niche backends don't use cg_ssa's linker code at all. If they do and don't work with lld, they can always disable lld usage using a cli argument.
Without this commit using cg_clif is by default in a non-trivial amount of cases a perf regression on Linux due to ld.bfd being a fair bit slower than lld. It is possible to explicitly enable it without this commit, but most users are unlikely to do this.