-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Failed to compile a project with LTO + PGO #115344
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
Comments
Were you able to reproduce this without using cargo pgo, by using the compiler flags manually? (-Cprofile-generate etc.) |
I haven't tried to do it yet but I will (and then report the results here) |
My project was done using the flags directly. See https://gitlab.com/kevincox/ricochetrobots/-/blob/6bbc44ddbf2ab8ae9edcbdca62e3035572f9c1ed/default.nix#L41-57 # Cargo.toml
[profile.release]
codegen-units = 1
lto = true
module flag identifiers must be unique (or of 'require' type) !"CG Profile" LLVM ERROR: Broken module found, compilation aborted! error: could not compile `ricochetrobots` (bin "ricochetrobots-debug-precompute") warning: build failed, waiting for other jobs to finish... module flag identifiers must be unique (or of 'require' type) !"CG Profile" LLVM ERROR: Broken module found, compilation aborted! error: could not compile `ricochetrobots` (bin "solve") [naersk] cargo returned with exit code 101, exiting |
I'm using the compiler flag directly (via
The file is confirmed to exist via
My PGO+LTO setup worked with Rust 1.66.1, but doesn't work with 1.71.1. |
This "file does not exist" error seems like a different one from the OP ("LLVM ERROR: Broken module found, compilation aborted!"), and it would be good to have a small self-contained example for your new error -- and possibly a dedicated issue since it also looks different from #63609. It feels possible to investigate in |
I got the same issue during the ruff optimization with PGO with
Note that Ruff also enables LTO as a part of its Release profile. When I switch off LTO, Additional details -
Tested the same scenario on my Linux machine (Fedora 38, x86-64) for the same scenario with the same Rust version and got the same error. |
Another affected project - https://github.com/foundry-rs/foundry Got the same error during
|
|
Indeed. I have a workaround for now ( |
In my case the compilation was happening clean, so incremental doesn't seem like the problem for me. |
Another example of hitting this error with
Also, I've checked cleaning the build directory before the PGO optimization build - didn't help. Dust also enables LTO in its Release profile. |
Uhh, so I was able to reproduce this on Linux (with just |
I need to recheck but AFAIK I remember some Rust projects there LTO + PGO worked fine... :) |
Yeah it's something specific in the project causing it, I'm trying to minimize |
@Kobzol Were you able to reproduce the issue? I have reproduced it once again with the latest Fedora 38 and Rust stable 1.73 and Ruff project on the latest commit |
Another affected project: https://github.com/googleforgames/quilkin . When
OS: Fedora 38 |
Another affected project - https://github.com/ImageOptim/gifski . On Linux with Rust 1.73 I get the same error:
Additional information:
|
Thanks for use clap::Command;
fn main() {
Command::new("a").about("a");
} in combination with this in [lib]
crate-type = ["lib", "cdylib"] and LTO=thin. I'll probably post this as a new issue and try to investigate more. |
Project - https://github.com/infinyon/fluvio-jolt Using Error:
OS: Fedora 40 |
Project - https://github.com/anacrolix/possum When I enable LTO (add
OS: Fedora 40 |
Do anyone have any idea what and how we may fix this issue, as it seem to affect a lot of projects? @Kobzol? |
Also happens when trying to compile polars with PGO Edit: |
Project - https://github.com/mwlon/pcodec After enabling LTO with
Fedora 40 |
Project - https://git.picodata.io/picodata/picodata/picodata Error:
Fedora 41 |
@dianqk It would be incredible if you managed to fix this |
[WIP] The embedded bitcode should always be prepared for LTO/ThinLTO Fixes rust-lang#115344. Fixes rust-lang#117220. r? ghost
[WIP] The embedded bitcode should always be prepared for LTO/ThinLTO Fixes rust-lang#115344. Fixes rust-lang#117220. r? ghost
A candidate PR: #133250. |
@dianqk you are an amazing human being! 💟 |
The embedded bitcode should always be prepared for LTO/ThinLTO Fixes rust-lang#115344. Fixes rust-lang#117220. There are currently two methods for generating bitcode that used for LTO. One method involves using `-C linker-plugin-lto` to emit object files as bitcode, which is the typical setting used by cargo. The other method is through `-C embed-bitcode=yes`. When using with `-C embed-bitcode=yes -C lto=no`, we run a complete non-LTO LLVM pipeline to obtain bitcode, then the bitcode is used for LTO. We run the Call Graph Profile Pass twice on the same module. This PR is doing something similar to LLVM's `buildFatLTODefaultPipeline`, obtaining the bitcode for embedding after running `buildThinLTOPreLinkDefaultPipeline`. r? nikic
The embedded bitcode should always be prepared for LTO/ThinLTO Fixes rust-lang#115344. Fixes rust-lang#117220. There are currently two methods for generating bitcode that used for LTO. One method involves using `-C linker-plugin-lto` to emit object files as bitcode, which is the typical setting used by cargo. The other method is through `-C embed-bitcode=yes`. When using with `-C embed-bitcode=yes -C lto=no`, we run a complete non-LTO LLVM pipeline to obtain bitcode, then the bitcode is used for LTO. We run the Call Graph Profile Pass twice on the same module. This PR is doing something similar to LLVM's `buildFatLTODefaultPipeline`, obtaining the bitcode for embedding after running `buildThinLTOPreLinkDefaultPipeline`. r? nikic
@zamazan4ik I imagine you might want to try out if it fixes the myriad of issues that you have reported 😁 Huge thanks to DianQK for working on this! |
Sorry for the delay from my side - I was busy a bit. I just tested the fix for Vector with the latest Rustc Nightly - vectordotdev/vector#15631 (comment) - the fix works like a charm! Thanks a lot for everyone who were participating in resolving this PGO blocker. I hope with this fix, we will see more PGO adoption in the Rust ecosystem. Maybe later I will perform more PGO benchmarks for the reported above projects, but it's not an urgent task as far as I see since the fix works great. UPD: I tested some other projects - for all of them the fix works fine. |
The embedded bitcode should always be prepared for LTO/ThinLTO Fixes rust-lang#115344. Fixes rust-lang#117220. There are currently two methods for generating bitcode that used for LTO. One method involves using `-C linker-plugin-lto` to emit object files as bitcode, which is the typical setting used by cargo. The other method is through `-C embed-bitcode=yes`. When using with `-C embed-bitcode=yes -C lto=no`, we run a complete non-LTO LLVM pipeline to obtain bitcode, then the bitcode is used for LTO. We run the Call Graph Profile Pass twice on the same module. This PR is doing something similar to LLVM's `buildFatLTODefaultPipeline`, obtaining the bitcode for embedding after running `buildThinLTOPreLinkDefaultPipeline`. r? nikic
The embedded bitcode should always be prepared for LTO/ThinLTO Fixes rust-lang#115344. Fixes rust-lang#117220. There are currently two methods for generating bitcode that used for LTO. One method involves using `-C linker-plugin-lto` to emit object files as bitcode, which is the typical setting used by cargo. The other method is through `-C embed-bitcode=yes`. When using with `-C embed-bitcode=yes -C lto=no`, we run a complete non-LTO LLVM pipeline to obtain bitcode, then the bitcode is used for LTO. We run the Call Graph Profile Pass twice on the same module. This PR is doing something similar to LLVM's `buildFatLTODefaultPipeline`, obtaining the bitcode for embedding after running `buildThinLTOPreLinkDefaultPipeline`. r? nikic
In vectordotdev/vector#15631 (comment) I tried to optimize Vector with LTO + PGO enabled. But during the optimization phase (done with
cargo pgo optimize
) I get the following error: Kobzol/cargo-pgo#32 (comment) . I am not the only person with this error - llvm/llvm-project#57501 (comment) (@kevincox probably can provide more details about they project).The only way to avoid the bug is disable LTO completely (switching from Fat to Thin mode does not help).
I expected to see this happen: Vector compiles successfully with LTO and PGO enabled.
Instead, this happened: Vector failed to compile with LTO + PGO.
Meta
rustc --version --verbose
(from https://github.com/vectordotdev/vector/blob/master/rust-toolchain.toml):Other links:
cargo-pgo
: LLVM ERROR: Broken module found, compilation aborted Kobzol/cargo-pgo#32The text was updated successfully, but these errors were encountered: