-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow use of -Clto=thin
with -Ccodegen-units=1
in general
#103610
Conversation
The current logic to ignore ThinLTO when `-Ccodegen-units=1` makes sense for local ThinLTO but even in this scenario, a user may still want (non-local) ThinLTO for the purpose of optimizing dependencies into the final crate which is being compiled with 1 CGU. The previous behavior was even more confusing because if you were generating a binary (`--emit=link`), then you would get ThinLTO but if you asked for LLVM IR or bytecode, then it would silently change to using regular LTO. With this change, we only override the defaults for local ThinLTO if you ask for a single output such as LLVM IR or bytecode and in all other cases honor the requested LTO setting.
I originally wanted to do a crater run for this but now I'm wondering if crater could even find anything here, given that the change only affects But let's do one anyway, to be on the safe side: @bors try |
⌛ Trying commit 7c6345d with merge 14accda7ba2c586835d15379a621955d9f047371... |
☀️ Try build successful - checks-actions |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
@craterbot run mode=build-only |
👌 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🚧 Experiment ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more |
🎉 Experiment
|
I looked through the crater results and didn't see anything very concerning. Most (probably like 75%) of the failures are because the node ran out of disk space during the build and there are lot of various error messages from rustc/llvm/ld failing due to IO errors. The next most common error was an older version of the libc crate failing to parse rustc's version (probably because of the Finally, there was one crate that failed to link because of duplicate symbols (https://github.com/lann/code-snippets). The crate appears to indirectly depend on multiple versions of I can try to investigate further if we think that is warranted. |
I can't find anything in either of those projects that looks like it would use the features in question. I don't think the build failure is related to this PR. @bors r+ |
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#99801 (fix(generic_const_exprs): Fix predicate inheritance for children of opaque types) - rust-lang#103610 (Allow use of `-Clto=thin` with `-Ccodegen-units=1` in general) - rust-lang#103870 (Fix `inferred_kind` ICE) - rust-lang#103875 (Simplify astconv item def id handling) - rust-lang#103886 (rustdoc: Fix merge of attributes for reexports of local items) - rust-lang#103890 (rustdoc: remove unused mobile CSS `.rustdoc { padding-top: 0 }`) Failed merges: - rust-lang#103884 (Add visit_fn_ret_ty to hir intravisit) r? `@ghost` `@rustbot` modify labels: rollup
cargo-show-asm relies on --emit to tell it which file was generated, In rustc past rust-lang/rust#103610 this no longer works even with -Ccodegen-units=1 This should not affect c-s-a's output since it wasn't looking at linker's optimization but might affect how compiled program performs.
FWIW this broke |
The current logic to ignore ThinLTO when
-Ccodegen-units=1
makes sense for local ThinLTO but even in this scenario, a user may still want (non-local) ThinLTO for the purpose of optimizing dependencies into the final crate which is being compiled with 1 CGU.The previous behavior was even more confusing because if you were generating a binary (
--emit=link
), then you would get ThinLTO but if you asked for LLVM IR or bytecode, then it would silently change to using regular LTO.With this change, we only override the defaults for local ThinLTO if you ask for a single output such as LLVM IR or bytecode and in all other cases honor the requested LTO setting.
r? @michaelwoerister