try to make rustc-dev work with and without LTO - #161535
Draft
RalfJung wants to merge 1 commit into
Draft
Conversation
rustbot
added
S-waiting-on-author
Member
Author
|
@bors try jobs=dist*linux |
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 22, 2026
try to make rustc-dev work with and without LTO try-job: dist*linux
This comment has been minimized.
This comment has been minimized.
Member
TIL glob is supported. |
Zoxc
reviewed
Aug 22, 2026
| // Compiling C deps, like jemalloc and llvm-wrapper, should be with | ||
| // the same LTO mode as the Rust code they are linked into. | ||
| // Compiling C deps, like jemalloc and llvm-wrapper, should be with the same LTO mode as | ||
| // the Rust code they are linked into. We don't pass the checks cc-rs uses to |
Contributor
There was a problem hiding this comment.
should be with the same LTO mode as the Rust code they are linked into
Just a note that this doesn't seem very true.
Member
There was a problem hiding this comment.
FWIW, the discussion happens in #t-compiler > Analysing broken jemalloc rlib
Member
Author
There was a problem hiding this comment.
Just a note that this doesn't seem very true.
I just reformatted that comment, I don't know if it is correct.
What would be more correct?
Member
|
Should we do something like this after the if lto_cflag.is_some()
&& builder.config.bootstrap_override_lld.is_used()
&& !target.is_msvc()
{
self.rustflags.arg("-Clink-args=-Wl,--fat-lto-objects");
}I am testing dist build on my machine still though. |
Contributor
Member
|
I guess we want a perf build @rust-timer build a4edfb9 |
This comment has been minimized.
This comment has been minimized.
Member
Author
I have no idea. |
Collaborator
|
Finished benchmarking commit (a4edfb9): comparison URL. Overall result: ❌ regressions - please read:Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf. Next, please: If you can, justify the regressions found in this try perf run in writing along with @bors rollup=never rustc-perf Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -2.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 3.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 469.195s -> 470.485s (0.27%) |
Member
Author
|
This did fix Miri but I guess it also broke LTO. I'll try the magic linker incantation you mentioned above then. |
RalfJung
force-pushed
the
aarch64-lto-compat
branch
from
August 22, 2026 21:32
8975695 to
d2077da
Compare
Member
Author
|
@bors try jobs=dist*linux |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
rustbot
added
the
S-waiting-on-perf
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 22, 2026
try to make rustc-dev work with and without LTO try-job: dist*linux
RalfJung
commented
Aug 22, 2026
| // Make sure the linker actually uses the fat LTO part. | ||
| if lto_cflag.is_some() | ||
| && builder.config.bootstrap_override_lld.is_used() | ||
| && !target.is_msvc() |
Member
Author
There was a problem hiding this comment.
FWIW I don't understand why we need to check for MSVC here, given that above we already check for clang.
Also, when does it ever make sense to set -ffat-lto-objects without setting the link-args as well?
Member
There was a problem hiding this comment.
IIRC clang-cl.exe still produces COFF object, right? So even it is clang-like we should not pass that link arg, as it is not supported yet.
https://llvm.org/docs/FatLTO.html#supported-file-formats
Or alternativelu we should just apply to x86_64 Linux as we previously discussed.
Member
There was a problem hiding this comment.
https://releases.llvm.org/22.1.0/tools/lld/docs/ReleaseNotes.html#coff-improvements
Oh! In LLVM 22 COFF gains the support of fat LTO.
Though according to bjorn3 we are still on 21 right now.
Member
There was a problem hiding this comment.
Also, when does it ever make sense to set -ffat-lto-objects without setting the link-args as well?
And yeah it probably makes little sense. We may be able to just figure out the minimal condition and coerce them in one of block
Member
There was a problem hiding this comment.
Maybe the entire code can be simplified to this?
let lto_cflag = if matches!(self.mode, Mode::Rustc | Mode::ToolRustcPrivate)
&& is_lto_stage(&self.compiler)
&& builder.cc_tool(target).is_like_clang()
&& builder.config.bootstrap_override_lld.is_used() // unsure if we should take care of non-dist config for downstream packagers
{
let lto_cflag = match builder.config.rust_lto {
RustcLto::Thin => Some("-flto=thin -ffat-lto-objects"),
RustcLto::Fat => Some("-flto=full -ffat-lto-objects"),
RustcLto::ThinLocal | RustcLto::Off => None,
};
if lto_cflag.is_some() {
self.rustflags.arg("-Clink-args=-Wl,--fat-lto-objects");
}
lto_cflag
} else {
None
};
Member
Contributor
This comment has been minimized.
This comment has been minimized.
Collaborator
|
Finished benchmarking commit (5db500f): comparison URL. Overall result: ❌ regressions - no action neededBenchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up. @rustbot label: -S-waiting-on-perf -perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)This perf run didn't have relevant results for this metric. CyclesResults (secondary -8.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (primary -0.0%, secondary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 468.574s -> 466.803s (-0.38%) |
rustbot
removed
S-waiting-on-perf
Member
Member
Author
|
On aarch64-linux, the rustc-dev component went from 125 MiB to 128 MiB. That seems fine? That's compressed size obviously though, so this may consume a lot more disk space if it compresses very well. If I check locally the whole folder |
RalfJung
force-pushed
the
aarch64-lto-compat
branch
from
August 23, 2026 06:40
d2077da to
7fe93be
Compare
rustbot
added
A-CI
Member
Author
|
@bors try jobs=distlinux,distmsvc,dist*apple |
Contributor
|
⌛ Trying commit 7fe93be with merge 956a99e… To cancel the try build, run the command Workflow: https://github.com/rust-lang/rust/actions/runs/32623605480 |
rust-bors Bot
pushed a commit
that referenced
this pull request
Aug 23, 2026
try to make rustc-dev work with and without LTO try-job: dist*linux try-job: dist*msvc try-job: dist*apple
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
RalfJung
commented
Aug 23, 2026
|
|
||
| # FIXME: Without this, LLVMgold.so incorrectly resolves to the system | ||
| # libstdc++, instead of the one we build. | ||
| ENV LD_PRELOAD=/rustroot/lib64/libstdc++.so.6 |
Member
Author
There was a problem hiding this comment.
I also removed this because maybe we don't need it any more?
Member
Author
There was a problem hiding this comment.
Though reading this now I guess what this is trying to say (but mostly leaving implicit) is that we need this LD_PRELOAD so that the LTO linker plugin works, i.e. without this the build succeeds but we don't get LTO?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
View all comments
This might fix the issues introduced by #161260.