diff options
| author | bors <bors@rust-lang.org> | 2025-03-01 08:22:18 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2025-03-01 08:22:18 +0000 |
| commit | 24b202f0c013c6665303463a08b52373b55cd02e (patch) | |
| tree | f8ab339909a44ca9f27e111e189d9955caed78b5 /tests/codegen/src-hash-algorithm/src-hash-algorithm-sha1.rs | |
| parent | b627900585c4d52ba7490bca0b2d1e580b40f815 (diff) | |
| parent | 9b8701d27ebc49b2ade98d910b411d6f0a57a0ac (diff) | |
| download | rust-24b202f0c013c6665303463a08b52373b55cd02e.tar.gz rust-24b202f0c013c6665303463a08b52373b55cd02e.zip | |
Auto merge of #133250 - DianQK:embed-bitcode-pgo, r=nikic
The embedded bitcode should always be prepared for LTO/ThinLTO Fixes #115344. Fixes #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
Diffstat (limited to 'tests/codegen/src-hash-algorithm/src-hash-algorithm-sha1.rs')
0 files changed, 0 insertions, 0 deletions