Fix linker-plugin-lto only doing thin lto

When rust provides LLVM bitcode files to lld and the bitcode contains
function summaries as used for thin lto, lld defaults to using thin lto.
This prevents some optimizations that are only applied for fat lto. I
ran into this with the amdgpu backend and was able to create a test
there. Unfortunately, I wasn’t able to recreate the same test on x86,
the difference between thin and fat lto seems less pronounced there.

The important part of the change is setting the `ThinLTO=0` module flag.
The rest of the changes are fixing the `<function>.kd` symbol getting
exported for amdhsa with linker-plugin-lto.

Author: Flakebi

compiler/rustc_codegen_llvm/src/context.rs

@@ -21,10 +21,10 @@ use rustc_middle::ty::layout::{
 };
 use rustc_middle::ty::{self, Instance, Ty, TyCtxt};
 use rustc_middle::{bug, span_bug};
-use rustc_session::Session;
 use rustc_session::config::{
     BranchProtection, CFGuard, CFProtection, CrateType, DebugInfo, FunctionReturn, PAuthKey, PacRet,
 };
+use rustc_session::{Session, config};
 use rustc_span::source_map::Spanned;
 use rustc_span::{DUMMY_SP, Span};
 use rustc_target::spec::{HasTargetSpec, RelocModel, SmallDataThresholdSupport, Target, TlsModel};
@@ -290,6 +290,11 @@ pub(crate) unsafe fn create_module<'ll>(
         );
     }
 
+    // Disable ThinLTO if fat lto is requested. Otherwise lld defaults to thin lto.
+    if sess.lto() == config::Lto::Fat {
+        llvm::add_module_flag_u32(llmod, llvm::ModuleFlagMergeBehavior::Override, "ThinLTO", 0);
+    }
+
     // Add "kcfi" module flag if KCFI is enabled. (See https://reviews.llvm.org/D119296.)
     if sess.is_sanitizer_kcfi_enabled() {
         llvm::add_module_flag_u32(llmod, llvm::ModuleFlagMergeBehavior::Override, "kcfi", 1);

compiler/rustc_codegen_ssa/src/back/link.rs

@@ -2549,8 +2549,14 @@ fn add_order_independent_options(
         // as it appears to be unused. This can then cause the PGO profile file to lose
         // some functions. If we are generating a profile we shouldn't strip those metadata
         // sections to ensure we have all the data for PGO.
-        let keep_metadata =
-            crate_type == CrateType::Dylib || sess.opts.cg.profile_generate.enabled();
+        let dylib_pgo = crate_type == CrateType::Dylib || sess.opts.cg.profile_generate.enabled();
+        // When compiling for amdhsa, every kernel function generates a <function name>.kd symbol.
+        // This symbol gets removed again when using linker-plugin-lto. Disable gc_sections to keep
+        // the symbol.
+        let amdhsa_linker_lto =
+            sess.target.os == "amdhsa" && sess.opts.cg.linker_plugin_lto.enabled();
+
+        let keep_metadata = dylib_pgo || amdhsa_linker_lto;
         if crate_type != CrateType::Executable || !sess.opts.unstable_opts.export_executable_symbols
         {
             cmd.gc_sections(keep_metadata);

compiler/rustc_codegen_ssa/src/back/linker.rs

@@ -839,7 +839,20 @@ impl<'a> Linker for GccLinker<'a> {
         } else {
             let mut arg = OsString::from("--version-script=");
             arg.push(path);
-            self.link_arg(arg).link_arg("--no-undefined-version");
+            self.link_arg(arg);
+
+            if self.sess.target.os == "amdhsa" && self.sess.opts.cg.linker_plugin_lto.enabled() {
+                // If we are compiling for amdhsa, kernel functions generate a symbol
+                // <function name>.kd in the LLVM backend, which needs to be visible in the output.
+                // But if we give bitcode to the linker, the symbol is not yet defined and the
+                // linker complains about an undefined symbol in the version script.
+                // At the same time, if we do not specify the <function name>.kd symbol in the
+                // version script, it will not be exported.
+                // Workaround by allowing the version script do contain undefined symbols.
+                self.link_arg("--undefined-version");
+            } else {
+                self.link_arg("--no-undefined-version");
+            }
         }
     }
 

tests/run-make/linker-plugin-lto-fat/lib.rs

@@ -0,0 +1,9 @@
+#![feature(no_core, lang_items)]
+#![no_core]
+#![crate_type = "staticlib"]
+
+#[lang = "sized"]
+trait Sized {}
+
+#[no_mangle]
+extern "C" fn foo() {}

tests/run-make/linker-plugin-lto-fat/main.rs

@@ -0,0 +1,17 @@
+#![feature(no_core, abi_gpu_kernel, lang_items)]
+#![no_core]
+#![crate_type = "cdylib"]
+
+#[lang = "sized"]
+trait Sized {}
+
+extern "C" {
+    fn foo();
+}
+
+#[no_mangle]
+extern "gpu-kernel" fn bar() {
+    unsafe {
+        foo();
+    }
+}

tests/run-make/linker-plugin-lto-fat/rmake.rs

@@ -0,0 +1,41 @@
+// Check that lto with -C linker-plugin-lto actually works and can inline functions.
+// A static library is compiled, defining a function. Then a dylib is compiled,
+// linking to the static library and calling the function from the library.
+// The function from the library should end up inlined and disappear from the output.
+
+//@ needs-llvm-components: amdgpu
+//@ needs-rust-lld
+
+#![feature(path_file_prefix)]
+
+use run_make_support::{dynamic_lib_name, llvm_readobj, rustc, static_lib_name};
+
+fn main() {
+    rustc()
+        .input("lib.rs")
+        .output(static_lib_name("lib"))
+        .args(&["-Clinker-plugin-lto", "--target=amdgcn-amd-amdhsa", "-Ctarget-cpu=gfx900"])
+        .run();
+    rustc()
+        .input("main.rs")
+        .output("main.elf")
+        .opt_level("3")
+        .args(&[
+            "-Clinker-plugin-lto",
+            "--target=amdgcn-amd-amdhsa",
+            "-Ctarget-cpu=gfx900",
+            &format!("-Clink-arg={}", static_lib_name("lib")),
+        ])
+        .run();
+
+    llvm_readobj()
+        .input("main.elf")
+        .symbols()
+        .run()
+        // The linked function should disappear.
+        .assert_stdout_not_contains("foo")
+        // The function from main.rs should still be there
+        .assert_stdout_contains("bar")
+        // and the kernel descriptor .kd symbol as well.
+        .assert_stdout_contains("bar.kd");
+}