rust/tests/codegen/pgo-counter-bias.rs

// Test that __llvm_profile_counter_bias does not get internalized by lto.

//@ ignore-apple -runtime-counter-relocation not honored on Mach-O
//@ compile-flags: -Cprofile-generate -Cllvm-args=-runtime-counter-relocation -Clto=fat
//@ compile-flags: -Zno-profiler-runtime
//@ no-prefer-dynamic

// CHECK: @__llvm_profile_counter_bias = {{.*}}global

pub fn main() {}
Don't internalize __llvm_profile_counter_bias Currently, LLVM profiling runtime counter relocation cannot be used by rust during LTO because symbols are being internalized before all symbol information is known. This mode makes LLVM emit a __llvm_profile_counter_bias symbol which is referenced by the profiling initialization, which itself is pulled in by the rust driver here [1]. It is enabled with -Cllvm-args=-runtime-counter-relocation for platforms which are opt-in to this mode like Linux. On these platforms there will be no link error, rather just surprising behavior for a user which request runtime counter relocation. The profiling runtime will not see that symbol go on as if it were never there. On Fuchsia, the profiling runtime must have this symbol which will cause a hard link error. As an aside, I don't have enough context as to why rust's LTO model is how it is. AFAICT, the internalize pass is only safe to run at link time when all symbol information is actually known, this being an example as to why. I think special casing this symbol as a known one that LLVM can emit which should not have it's visbility de-escalated should be fine given how seldom this pattern of defining an undefined symbol to get initilization code pulled in is. From a quick grep, __llvm_profile_runtime is the only symbol that rustc does this for. [1] https://github.com/rust-lang/rust/blob/0265a3e93bf1b89d97cae113ed214954d5c35e22/compiler/rustc_codegen_ssa/src/back/linker.rs#L598 2022-12-05 06:37:21 +00:00			`// Test that __llvm_profile_counter_bias does not get internalized by lto.`

Make more of the test suite run on Mac Catalyst This adds the `only-apple`/`ignore-apple` compiletest directive, and uses that basically everywhere instead of `only-macos`/`ignore-macos`. Some of the updates in `run-make` are a bit redundant, as they use `ignore-cross-compile` and won't run on iOS - but using Apple in these is still more correct, so I've made that change anyhow. 2024-05-27 15:17:18 +02:00			`//@ ignore-apple -runtime-counter-relocation not honored on Mach-O`
[AUTO_GENERATED] Migrate compiletest to use `ui_test`-style `//@` directives 2024-02-22 12:10:29 +00:00			`//@ compile-flags: -Cprofile-generate -Cllvm-args=-runtime-counter-relocation -Clto=fat`
Use `-Zno-profiler-runtime` instead of `//@ needs-profiler-support` For PGO/coverage tests that don't need to build or run an actual artifact, we can use `-Zno-profiler-runtime` to run the test even when the profiler runtime is not available. 2024-03-16 17:02:30 +11:00			`//@ compile-flags: -Zno-profiler-runtime`
[AUTO_GENERATED] Migrate compiletest to use `ui_test`-style `//@` directives 2024-02-22 12:10:29 +00:00			`//@ no-prefer-dynamic`
Don't internalize __llvm_profile_counter_bias Currently, LLVM profiling runtime counter relocation cannot be used by rust during LTO because symbols are being internalized before all symbol information is known. This mode makes LLVM emit a __llvm_profile_counter_bias symbol which is referenced by the profiling initialization, which itself is pulled in by the rust driver here [1]. It is enabled with -Cllvm-args=-runtime-counter-relocation for platforms which are opt-in to this mode like Linux. On these platforms there will be no link error, rather just surprising behavior for a user which request runtime counter relocation. The profiling runtime will not see that symbol go on as if it were never there. On Fuchsia, the profiling runtime must have this symbol which will cause a hard link error. As an aside, I don't have enough context as to why rust's LTO model is how it is. AFAICT, the internalize pass is only safe to run at link time when all symbol information is actually known, this being an example as to why. I think special casing this symbol as a known one that LLVM can emit which should not have it's visbility de-escalated should be fine given how seldom this pattern of defining an undefined symbol to get initilization code pulled in is. From a quick grep, __llvm_profile_runtime is the only symbol that rustc does this for. [1] https://github.com/rust-lang/rust/blob/0265a3e93bf1b89d97cae113ed214954d5c35e22/compiler/rustc_codegen_ssa/src/back/linker.rs#L598 2022-12-05 06:37:21 +00:00
			`// CHECK: @__llvm_profile_counter_bias = {{.*}}global`

			`pub fn main() {}`