bors 0c72c0d11a 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
2025-03-01 08:22:18 +00:00
..
2025-02-19 19:01:51 +01:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-21 21:51:20 -05:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-03 10:39:32 -05:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2024-12-10 21:41:05 +01:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-02-24 09:26:54 +00:00
2025-01-21 08:27:30 +00:00
2025-02-24 09:26:54 +00:00
2025-02-19 11:36:52 -08:00

The files here use the LLVM FileCheck framework, documented at https://llvm.org/docs/CommandGuide/FileCheck.html.

One extension worth noting is the use of revisions as custom prefixes for FileCheck. If your codegen test has different behavior based on the chosen target or different compiler flags that you want to exercise, you can use a revisions annotation, like so:

// revisions: aaa bbb
// [bbb] compile-flags: --flags-for-bbb

After specifying those variations, you can write different expected, or explicitly unexpected output by using <prefix>-SAME: and <prefix>-NOT:, like so:

// CHECK: expected code
// aaa-SAME: emitted-only-for-aaa
// aaa-NOT:                        emitted-only-for-bbb
// bbb-NOT:  emitted-only-for-aaa
// bbb-SAME:                       emitted-only-for-bbb