[PATCH v9 0/3] kbuild: distributed build support for Clang ThinLTO

[PATCH v9 0/3] kbuild: distributed build support for Clang ThinLTO

[xur]

From: Rong Xu <xur@google.com>

ChangeLog:

V9:  Fix minor build error.
V8:  Disabled -always-rename-promoted-locals=false for the distrubute
     mode, based on Yonghong and Nathan's comments.
V7: (1) Resolved a conflict by rebasing to kbuild/kbuild-next-unstable.
    (2) Separated the '--thin' to 'T' change into its own patch to
        preserve Masahiro's original version.
V6: Change '--thin' back to 'T' in Makefile.vmlinux_a to fix
    reported the build error from old ar.
V5: Handle single quote escaping in echo _c_flags to fix
    Piotr Gorski's reported error.
V4: This is based on the reimplementation provided by Masahiro Yamada
on May 26. The difference is that this version now saves the compiler
flags (_c_flags) from the Front-End (FE) compilation and re-uses them
for the subsequent Back-End (BE) compilation.

Rong Xu (3):
  kbuild: move vmlinux.a build rule to scripts/Makefile.vmlinux_a
  kbuild: change --thin back to 'T' in $(AR)
  kbuild: distributed build support for Clang ThinLTO

 .gitignore                 |  2 +
 Makefile                   | 27 ++++++-------
 arch/Kconfig               | 19 +++++++++
 scripts/Makefile.lib       |  7 ++++
 scripts/Makefile.thinlto   | 40 ++++++++++++++++++
 scripts/Makefile.vmlinux_a | 83 ++++++++++++++++++++++++++++++++++++++
 scripts/mod/modpost.c      | 15 +++++--
 7 files changed, 176 insertions(+), 17 deletions(-)
 create mode 100644 scripts/Makefile.thinlto
 create mode 100644 scripts/Makefile.vmlinux_a


base-commit: dcc99abebfa1e9ca70f8af8695b6682ad7597bf2
-- 
2.53.0.1018.g2bb0e51243-goog

[PATCH v9 1/3] kbuild: move vmlinux.a build rule to scripts/Makefile.vmlinux_a

[xur]

From: Rong Xu <xur@google.com>

From: Masahiro Yamada <masahiroy@kernel.org>

Move the build rule for vmlinux.a to a separate file in preparation
for supporting distributed builds with Clang ThinLTO.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Rong Xu <xur@google.com>
Signed-off-by: Rong Xu <xur@google.com>
---
 Makefile                   | 16 +++++--------
 scripts/Makefile.vmlinux_a | 46 ++++++++++++++++++++++++++++++++++++++
 2 files changed, 52 insertions(+), 10 deletions(-)
 create mode 100644 scripts/Makefile.vmlinux_a

diff --git a/Makefile b/Makefile
index a8d8ed711f9b..69ccf9b8507d 100644
--- a/Makefile
+++ b/Makefile
@@ -1264,7 +1264,7 @@ export ARCH_DRIVERS	:= $(drivers-y) $(drivers-m)
 KBUILD_VMLINUX_OBJS := built-in.a $(patsubst %/, %/lib.a, $(filter %/, $(libs-y)))
 KBUILD_VMLINUX_LIBS := $(filter-out %/, $(libs-y))
 
-export KBUILD_VMLINUX_LIBS
+export KBUILD_VMLINUX_OBJS KBUILD_VMLINUX_LIBS
 export KBUILD_LDS          := arch/$(SRCARCH)/kernel/vmlinux.lds
 
 ifdef CONFIG_TRIM_UNUSED_KSYMS
@@ -1273,16 +1273,12 @@ ifdef CONFIG_TRIM_UNUSED_KSYMS
 KBUILD_MODULES := y
 endif
 
-# '$(AR) mPi' needs 'T' to workaround the bug of llvm-ar <= 14
-quiet_cmd_ar_vmlinux.a = AR      $@
-      cmd_ar_vmlinux.a = \
-	rm -f $@; \
-	$(AR) cDPrST $@ $(KBUILD_VMLINUX_OBJS); \
-	$(AR) mPiT $$($(AR) t $@ | sed -n 1p) $@ $$($(AR) t $@ | grep -F -f $(srctree)/scripts/head-object-list.txt)
+PHONY += vmlinux_a
+vmlinux_a: $(KBUILD_VMLINUX_OBJS) scripts/head-object-list.txt FORCE
+	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux_a
 
-targets += vmlinux.a
-vmlinux.a: $(KBUILD_VMLINUX_OBJS) scripts/head-object-list.txt FORCE
-	$(call if_changed,ar_vmlinux.a)
+vmlinux.a: vmlinux_a
+	@:
 
 PHONY += vmlinux_o
 vmlinux_o: vmlinux.a $(KBUILD_VMLINUX_LIBS)
diff --git a/scripts/Makefile.vmlinux_a b/scripts/Makefile.vmlinux_a
new file mode 100644
index 000000000000..9774f02b43b2
--- /dev/null
+++ b/scripts/Makefile.vmlinux_a
@@ -0,0 +1,46 @@
+# SPDX-License-Identifier: GPL-2.0-only
+
+PHONY := __default
+__default: vmlinux.a
+
+include include/config/auto.conf
+include $(srctree)/scripts/Kbuild.include
+include $(srctree)/scripts/Makefile.lib
+
+# Link of built-in-fixup.a
+# ---------------------------------------------------------------------------
+
+# '$(AR) mPi' needs --thin to workaround the bug of llvm-ar <= 14
+quiet_cmd_ar_builtin_fixup = AR      $@
+      cmd_ar_builtin_fixup = \
+	rm -f $@; \
+	$(AR) cDPrS --thin $@ $(KBUILD_VMLINUX_OBJS); \
+	$(AR) mPi --thin $$($(AR) t $@ | sed -n 1p) $@ $$($(AR) t $@ | grep -F -f $(srctree)/scripts/head-object-list.txt)
+
+targets += built-in-fixup.a
+built-in-fixup.a: $(KBUILD_VMLINUX_OBJS) scripts/head-object-list.txt FORCE
+	$(call if_changed,ar_builtin_fixup)
+
+# vmlinux.a
+# ---------------------------------------------------------------------------
+
+targets += vmlinux.a
+vmlinux.a: built-in-fixup.a FORCE
+	$(call if_changed,copy)
+
+# Add FORCE to the prerequisites of a target to force it to be always rebuilt.
+# ---------------------------------------------------------------------------
+
+PHONY += FORCE
+FORCE:
+
+# Read all saved command lines and dependencies for the $(targets) we
+# may be building above, using $(if_changed{,_dep}). As an
+# optimization, we don't need to read them if the target does not
+# exist, we will rebuild anyway in that case.
+
+existing-targets := $(wildcard $(sort $(targets)))
+
+-include $(foreach f,$(existing-targets),$(dir $(f)).$(notdir $(f)).cmd)
+
+.PHONY: $(PHONY)
-- 
2.53.0.1018.g2bb0e51243-goog

[PATCH v9 2/3] kbuild: change --thin back to 'T' in $(AR)

[xur]

From: Rong Xu <xur@google.com>

The '-T' flag in $(AR) is no longer problematic since the minimum
requirement for LLVM has been updated to version 15. As of LLVM 14
and onward, the '-T' flag functions identically to the '--thin' flag.

Fixed the issue seen on IBM Power11 System:
  ar: unrecognized option '--thin'

Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Closes: https://lore.kernel.org/linux-next/476507c9-a371-4864-9e87-572c1ecae82d@linux.ibm.com/
Signed-off-by: Rong Xu <xur@google.com>
---
 scripts/Makefile.vmlinux_a | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/Makefile.vmlinux_a b/scripts/Makefile.vmlinux_a
index 9774f02b43b2..650d44330d1f 100644
--- a/scripts/Makefile.vmlinux_a
+++ b/scripts/Makefile.vmlinux_a
@@ -10,12 +10,12 @@ include $(srctree)/scripts/Makefile.lib
 # Link of built-in-fixup.a
 # ---------------------------------------------------------------------------
 
-# '$(AR) mPi' needs --thin to workaround the bug of llvm-ar <= 14
+# '$(AR) mPi' needs 'T' to workaround the bug of llvm-ar <= 14
 quiet_cmd_ar_builtin_fixup = AR      $@
       cmd_ar_builtin_fixup = \
 	rm -f $@; \
-	$(AR) cDPrS --thin $@ $(KBUILD_VMLINUX_OBJS); \
-	$(AR) mPi --thin $$($(AR) t $@ | sed -n 1p) $@ $$($(AR) t $@ | grep -F -f $(srctree)/scripts/head-object-list.txt)
+	$(AR) cDPrST $@ $(KBUILD_VMLINUX_OBJS); \
+	$(AR) mPiT $$($(AR) t $@ | sed -n 1p) $@ $$($(AR) t $@ | grep -F -f $(srctree)/scripts/head-object-list.txt)
 
 targets += built-in-fixup.a
 built-in-fixup.a: $(KBUILD_VMLINUX_OBJS) scripts/head-object-list.txt FORCE
-- 
2.53.0.1018.g2bb0e51243-goog

[PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[xur]

From: Rong Xu <xur@google.com>

Add distributed ThinLTO build support for the Linux kernel.
This new mode offers several advantages: (1) Increased
flexibility in handling user-specified build options.
(2) Improved user-friendliness for developers. (3) Greater
convenience for integrating with objtool and livepatch.

Note that "distributed" in this context refers to a term
that differentiates in-process ThinLTO builds by invoking
backend compilation through the linker, not necessarily
building in distributed environments.

Distributed ThinLTO is enabled via the
`CONFIG_LTO_CLANG_THIN_DIST` Kconfig option. For example:
 > make LLVM=1 defconfig
 > scripts/config -e LTO_CLANG_THIN_DIST
 > make LLVM=1 oldconfig
 > make LLVM=1 vmlinux -j <..>

The build flow proceeds in four stages:
  1. Perform FE compilation, mirroring the in-process ThinLTO mode.
  2. Thin-link the generated IR files and object files.
  3. Find all IR files and perform BE compilation, using the flags
    stored in the .*.o.cmd files.
  4. Link the BE results to generate the final vmlinux.o.

NOTE: This patch currently implements the build for the main kernel
image (vmlinux) only. Kernel module support is planned for a
subsequent patch.

Tested on the following arch: x86, arm64, loongarch, and
riscv.

The earlier implementation details can be found here:
https://discourse.llvm.org/t/rfc-distributed-thinlto-build-for-kernel/85934

Signed-off-by: Rong Xu <xur@google.com>
Co-developed-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
---
 .gitignore                 |  2 ++
 Makefile                   | 11 +++++++----
 arch/Kconfig               | 19 ++++++++++++++++++
 scripts/Makefile.lib       |  7 +++++++
 scripts/Makefile.thinlto   | 40 ++++++++++++++++++++++++++++++++++++++
 scripts/Makefile.vmlinux_a | 37 +++++++++++++++++++++++++++++++++++
 scripts/mod/modpost.c      | 15 +++++++++++---
 7 files changed, 124 insertions(+), 7 deletions(-)
 create mode 100644 scripts/Makefile.thinlto

diff --git a/.gitignore b/.gitignore
index 3a7241c941f5..c12bdf5a97f9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -56,6 +56,7 @@
 *.zst
 Module.symvers
 dtbs-list
+builtin.order
 modules.order
 
 #
@@ -67,6 +68,7 @@ modules.order
 /vmlinux.32
 /vmlinux.map
 /vmlinux.symvers
+/vmlinux.thinlto-index
 /vmlinux.unstripped
 /vmlinux-gdb.py
 /vmlinuz
diff --git a/Makefile b/Makefile
index 69ccf9b8507d..26005c64016d 100644
--- a/Makefile
+++ b/Makefile
@@ -1047,11 +1047,13 @@ export CC_FLAGS_SCS
 endif
 
 ifdef CONFIG_LTO_CLANG
-ifdef CONFIG_LTO_CLANG_THIN
+ifdef CONFIG_LTO_CLANG_FULL
+CC_FLAGS_LTO	:= -flto
+else
 CC_FLAGS_LTO	:= -flto=thin -fsplit-lto-unit
+if CONFIG_LTO_CLANG_THIN
 KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
-else
-CC_FLAGS_LTO	:= -flto
+endif
 endif
 CC_FLAGS_LTO	+= -fvisibility=hidden
 
@@ -1657,6 +1659,7 @@ endif # CONFIG_MODULES
 CLEAN_FILES += vmlinux.symvers modules-only.symvers \
 	       modules.builtin modules.builtin.modinfo modules.nsdeps \
 	       modules.builtin.ranges vmlinux.o.map vmlinux.unstripped \
+	       vmlinux.thinlto-index builtin.order \
 	       compile_commands.json rust/test \
 	       rust-project.json .vmlinux.objs .vmlinux.export.c \
                .builtin-dtbs-list .builtin-dtb.S
@@ -2118,7 +2121,7 @@ clean: $(clean-dirs)
 	$(call cmd,rmfiles)
 	@find . $(RCS_FIND_IGNORE) \
 		\( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
-		-o -name '*.ko.*' \
+		-o -name '*.ko.*' -o -name '*.o.thinlto.bc' \
 		-o -name '*.dtb' -o -name '*.dtbo' \
 		-o -name '*.dtb.S' -o -name '*.dtbo.S' \
 		-o -name '*.dt.yaml' -o -name 'dtbs-list' \
diff --git a/arch/Kconfig b/arch/Kconfig
index 102ddbd4298e..340550e44c50 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -861,6 +861,25 @@ config LTO_CLANG_THIN
 	    https://clang.llvm.org/docs/ThinLTO.html
 
 	  If unsure, say Y.
+
+config LTO_CLANG_THIN_DIST
+	bool "Clang ThinLTO in distributed mode (EXPERIMENTAL)"
+	depends on HAS_LTO_CLANG && ARCH_SUPPORTS_LTO_CLANG_THIN
+	select LTO_CLANG
+	help
+	  This option enables Clang's ThinLTO in distributed build mode.
+	  In this mode, the linker performs the thin-link, generating
+	  ThinLTO index files. Subsequently, the build system explicitly
+	  invokes ThinLTO backend compilation using these index files
+	  and pre-linked IR objects. The resulting native object files
+	  are with the .thinlto-native.o suffix.
+
+	  This build mode offers improved visibility into the ThinLTO
+	  process through explicit subcommand exposure. It also makes
+	  final native object files directly available, benefiting
+	  tools like objtool and kpatch. Additionally, it provides
+	  crucial granular control over back-end options, enabling
+	  module-specific compiler options, and simplifies debugging.
 endchoice
 
 config ARCH_SUPPORTS_AUTOFDO_CLANG
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 0718e39cedda..b36c7c6817bd 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -249,6 +249,12 @@ ifdef CONFIG_LTO_CLANG
 cmd_ld_single = $(if $(objtool-enabled)$(is-single-obj-m), ; $(LD) $(ld_flags) -r -o $(tmp-target) $@; mv $(tmp-target) $@)
 endif
 
+ifdef CONFIG_LTO_CLANG_THIN_DIST
+# Save the _c_flags, sliently.
+quiet_cmd_save_c_flags =
+      cmd_save_c_flags = printf '\n%s\n' 'saved_c_flags_$@ := $(call escsq,$(_c_flags))' >> $(dot-target).cmd
+endif
+
 quiet_cmd_cc_o_c = CC $(quiet_modtag)  $@
       cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< \
 		$(cmd_ld_single) \
@@ -256,6 +262,7 @@ quiet_cmd_cc_o_c = CC $(quiet_modtag)  $@
 
 define rule_cc_o_c
 	$(call cmd_and_fixdep,cc_o_c)
+	$(call cmd,save_c_flags)
 	$(call cmd,checksrc)
 	$(call cmd,checkdoc)
 	$(call cmd,gen_objtooldep)
diff --git a/scripts/Makefile.thinlto b/scripts/Makefile.thinlto
new file mode 100644
index 000000000000..03349ac69de5
--- /dev/null
+++ b/scripts/Makefile.thinlto
@@ -0,0 +1,40 @@
+PHONY := __default
+__default:
+
+include include/config/auto.conf
+include $(srctree)/scripts/Kbuild.include
+include $(srctree)/scripts/Makefile.lib
+
+native-objs := $(patsubst %.o,%.thinlto-native.o,$(call read-file, vmlinux.thinlto-index))
+
+__default: $(native-objs)
+
+# Generate .thinlto-native.o (obj) from .o (bitcode) and .thinlto.bc (summary) files
+# ---------------------------------------------------------------------------
+quiet_cmd_cc_o_bc = CC $(quiet_modtag)  $@
+      be_flags = $(shell sed -n '/saved_c_flags_/s/.*:= //p' \
+		 $(dir $(<)).$(notdir $(<)).cmd)
+      cmd_cc_o_bc = \
+      $(CC) $(be_flags) -x ir -fno-lto -Wno-unused-command-line-argument \
+      -fthinlto-index=$(word 2, $^) -c -o $@ $<
+
+targets += $(native-objs)
+$(native-objs): %.thinlto-native.o: %.o %.o.thinlto.bc   FORCE
+	$(call if_changed,cc_o_bc)
+
+# Add FORCE to the prerequisites of a target to force it to be always rebuilt.
+# ---------------------------------------------------------------------------
+
+PHONY += FORCE
+FORCE:
+
+# Read all saved command lines and dependencies for the $(targets) we
+# may be building above, using $(if_changed{,_dep}). As an
+# optimization, we don't need to read them if the target does not
+# exist, we will rebuild anyway in that case.
+
+existing-targets := $(wildcard $(sort $(targets)))
+
+-include $(foreach f,$(existing-targets),$(dir $(f)).$(notdir $(f)).cmd)
+
+.PHONY: $(PHONY)
diff --git a/scripts/Makefile.vmlinux_a b/scripts/Makefile.vmlinux_a
index 650d44330d1f..15d92ee82dee 100644
--- a/scripts/Makefile.vmlinux_a
+++ b/scripts/Makefile.vmlinux_a
@@ -21,6 +21,41 @@ targets += built-in-fixup.a
 built-in-fixup.a: $(KBUILD_VMLINUX_OBJS) scripts/head-object-list.txt FORCE
 	$(call if_changed,ar_builtin_fixup)
 
+ifdef CONFIG_LTO_CLANG_THIN_DIST
+
+quiet_cmd_builtin.order = GEN     $@
+      cmd_builtin.order = $(AR) t $< > $@
+
+targets += builtin.order
+builtin.order: built-in-fixup.a FORCE
+	$(call if_changed,builtin.order)
+
+quiet_cmd_ld_thinlto_index = LD      $@
+      cmd_ld_thinlto_index = \
+	$(LD) $(KBUILD_LDFLAGS) -r --thinlto-index-only=$@ @$<
+
+targets += vmlinux.thinlto-index
+vmlinux.thinlto-index: builtin.order FORCE
+	$(call if_changed,ld_thinlto_index)
+
+quiet_cmd_ar_vmlinux.a = GEN     $@
+      cmd_ar_vmlinux.a =					\
+	rm -f $@;						\
+	while read -r obj; do					\
+		if grep -q $${obj} $(word 2, $^); then		\
+			echo $${obj%.o}.thinlto-native.o;	\
+		else						\
+			echo $${obj};				\
+		fi;						\
+	done < $< | xargs $(AR) cDPrS --thin $@
+
+targets += vmlinux.a
+vmlinux.a: builtin.order vmlinux.thinlto-index FORCE
+	$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.thinlto
+	$(call if_changed,ar_vmlinux.a)
+
+else
+
 # vmlinux.a
 # ---------------------------------------------------------------------------
 
@@ -28,6 +63,8 @@ targets += vmlinux.a
 vmlinux.a: built-in-fixup.a FORCE
 	$(call if_changed,copy)
 
+endif
+
 # Add FORCE to the prerequisites of a target to force it to be always rebuilt.
 # ---------------------------------------------------------------------------
 
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 0c25b5ad497b..b3c3cf42c9eb 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1482,13 +1482,22 @@ static void extract_crcs_for_object(const char *object, struct module *mod)
 	char cmd_file[PATH_MAX];
 	char *buf, *p;
 	const char *base;
-	int dirlen, ret;
+	int dirlen, baselen_without_suffix, ret;
 
 	base = get_basename(object);
 	dirlen = base - object;
 
-	ret = snprintf(cmd_file, sizeof(cmd_file), "%.*s.%s.cmd",
-		       dirlen, object, base);
+	baselen_without_suffix = strlen(object) - dirlen - strlen(".o");
+
+	/*
+	 * When CONFIG_LTO_CLANG_THIN_DIST=y, the ELF is *.thinlto-native.o
+	 * but the symbol CRCs are recorded in *.o.cmd file.
+	 */
+	if (strends(object, ".thinlto-native.o"))
+		baselen_without_suffix -= strlen(".thinlto-native");
+
+	ret = snprintf(cmd_file, sizeof(cmd_file), "%.*s.%.*s.o.cmd",
+		       dirlen, object, baselen_without_suffix, base);
 	if (ret >= sizeof(cmd_file)) {
 		error("%s: too long path was truncated\n", cmd_file);
 		return;
-- 
2.53.0.1018.g2bb0e51243-goog

Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[Nathan Chancellor]

Hi Rong,

On Tue, Mar 31, 2026 at 03:48:27PM +0000, xur@google.com wrote:
> diff --git a/Makefile b/Makefile
> index 69ccf9b8507d..26005c64016d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1047,11 +1047,13 @@ export CC_FLAGS_SCS
>  endif
>  
>  ifdef CONFIG_LTO_CLANG
> -ifdef CONFIG_LTO_CLANG_THIN
> +ifdef CONFIG_LTO_CLANG_FULL
> +CC_FLAGS_LTO	:= -flto
> +else
>  CC_FLAGS_LTO	:= -flto=thin -fsplit-lto-unit
> +if CONFIG_LTO_CLANG_THIN

This should be an 'ifdef', not an 'if'. You copied Yonghong's mistake:

  https://lore.kernel.org/abgRRX3PH9IaExi8@sirena.org.uk/
  https://lore.kernel.org/6db3a2f6-d61c-42f1-9b9d-0aca021cc2d7@linux.dev/

Please slow down and test build your changes before sending them. Each
revision adds four new emails to everyone's inbox, which is just noise
when there are obvious, basic problems. 'b4 diff' shows no actual
difference from v8 and v9, which should have been caught by a simple
build test right before 'git send-email'.

>  KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> -else
> -CC_FLAGS_LTO	:= -flto
> +endif
>  endif
>  CC_FLAGS_LTO	+= -fvisibility=hidden
>  
> @@ -1657,6 +1659,7 @@ endif # CONFIG_MODULES
>  CLEAN_FILES += vmlinux.symvers modules-only.symvers \
>  	       modules.builtin modules.builtin.modinfo modules.nsdeps \
>  	       modules.builtin.ranges vmlinux.o.map vmlinux.unstripped \
> +	       vmlinux.thinlto-index builtin.order \
>  	       compile_commands.json rust/test \
>  	       rust-project.json .vmlinux.objs .vmlinux.export.c \
>                 .builtin-dtbs-list .builtin-dtb.S
> @@ -2118,7 +2121,7 @@ clean: $(clean-dirs)
>  	$(call cmd,rmfiles)
>  	@find . $(RCS_FIND_IGNORE) \
>  		\( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
> -		-o -name '*.ko.*' \
> +		-o -name '*.ko.*' -o -name '*.o.thinlto.bc' \
>  		-o -name '*.dtb' -o -name '*.dtbo' \
>  		-o -name '*.dtb.S' -o -name '*.dtbo.S' \
>  		-o -name '*.dt.yaml' -o -name 'dtbs-list' \

With that addressed above, the series survives my basic LLVM 22.1.2
build test with my distribution configuration. I'll provide formal tags
on a properly tested and fixed revision.

Cheers,
Nathan

Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[Yonghong Song]

On 3/31/26 9:27 AM, Nathan Chancellor wrote:
> Hi Rong,
>
> On Tue, Mar 31, 2026 at 03:48:27PM +0000, xur@google.com wrote:
>> diff --git a/Makefile b/Makefile
>> index 69ccf9b8507d..26005c64016d 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1047,11 +1047,13 @@ export CC_FLAGS_SCS
>>   endif
>>   
>>   ifdef CONFIG_LTO_CLANG
>> -ifdef CONFIG_LTO_CLANG_THIN
>> +ifdef CONFIG_LTO_CLANG_FULL
>> +CC_FLAGS_LTO	:= -flto
>> +else
>>   CC_FLAGS_LTO	:= -flto=thin -fsplit-lto-unit
>> +if CONFIG_LTO_CLANG_THIN
> This should be an 'ifdef', not an 'if'. You copied Yonghong's mistake:
>
>    https://lore.kernel.org/abgRRX3PH9IaExi8@sirena.org.uk/
>    https://lore.kernel.org/6db3a2f6-d61c-42f1-9b9d-0aca021cc2d7@linux.dev/
>
> Please slow down and test build your changes before sending them. Each
> revision adds four new emails to everyone's inbox, which is just noise
> when there are obvious, basic problems. 'b4 diff' shows no actual
> difference from v8 and v9, which should have been caught by a simple
> build test right before 'git send-email'.
>
>>   KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
>> -else
>> -CC_FLAGS_LTO	:= -flto
>> +endif

The above patch has a guard CONFIG_LTO_CLANG_THIN, which can be removed.
See llvm patch
    https://github.com/llvm/llvm-project/pull/188074
which supports distributed thin-lto mode too for reducing the number
of renaming. In other words, for llvm23, both in-process and
distributed-process are supported for thin-lto.

>>   endif
>>   CC_FLAGS_LTO	+= -fvisibility=hidden
>>   
>> @@ -1657,6 +1659,7 @@ endif # CONFIG_MODULES
>>   CLEAN_FILES += vmlinux.symvers modules-only.symvers \
>>   	       modules.builtin modules.builtin.modinfo modules.nsdeps \
>>   	       modules.builtin.ranges vmlinux.o.map vmlinux.unstripped \
>> +	       vmlinux.thinlto-index builtin.order \
>>   	       compile_commands.json rust/test \
>>   	       rust-project.json .vmlinux.objs .vmlinux.export.c \
>>                  .builtin-dtbs-list .builtin-dtb.S
>> @@ -2118,7 +2121,7 @@ clean: $(clean-dirs)
>>   	$(call cmd,rmfiles)
>>   	@find . $(RCS_FIND_IGNORE) \
>>   		\( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
>> -		-o -name '*.ko.*' \
>> +		-o -name '*.ko.*' -o -name '*.o.thinlto.bc' \
>>   		-o -name '*.dtb' -o -name '*.dtbo' \
>>   		-o -name '*.dtb.S' -o -name '*.dtbo.S' \
>>   		-o -name '*.dt.yaml' -o -name 'dtbs-list' \
> With that addressed above, the series survives my basic LLVM 22.1.2
> build test with my distribution configuration. I'll provide formal tags
> on a properly tested and fixed revision.
>
> Cheers,
> Nathan

Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[Rong Xu]

Yonghong, thanks for the update.

Regarding this guard: ther is a period of Clang (before this patch and
after your first patch), even though ld.lld having these options
(specifically --lto-whole-program-visibility -mllvm
-always-rename-promoted-locals=false), distributed ThinLTO mode
remains unsupported, correct? What the behvior of using this options
in distributed mode with these compilers? nop or it will lead to
error?

I would assume there will be errors; otherwise, you would not ask me
to change my patch last time. In this case, I would keep this guard
and remove it when the minimum llvm version passes llvm23. What do you
think?

Best,

-Rong


On Thu, May 21, 2026 at 1:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>
>
>
> On 3/31/26 9:27 AM, Nathan Chancellor wrote:
> > Hi Rong,
> >
> > On Tue, Mar 31, 2026 at 03:48:27PM +0000, xur@google.com wrote:
> >> diff --git a/Makefile b/Makefile
> >> index 69ccf9b8507d..26005c64016d 100644
> >> --- a/Makefile
> >> +++ b/Makefile
> >> @@ -1047,11 +1047,13 @@ export CC_FLAGS_SCS
> >>   endif
> >>
> >>   ifdef CONFIG_LTO_CLANG
> >> -ifdef CONFIG_LTO_CLANG_THIN
> >> +ifdef CONFIG_LTO_CLANG_FULL
> >> +CC_FLAGS_LTO        := -flto
> >> +else
> >>   CC_FLAGS_LTO       := -flto=thin -fsplit-lto-unit
> >> +if CONFIG_LTO_CLANG_THIN
> > This should be an 'ifdef', not an 'if'. You copied Yonghong's mistake:
> >
> >    https://lore.kernel.org/abgRRX3PH9IaExi8@sirena.org.uk/
> >    https://lore.kernel.org/6db3a2f6-d61c-42f1-9b9d-0aca021cc2d7@linux.dev/
> >
> > Please slow down and test build your changes before sending them. Each
> > revision adds four new emails to everyone's inbox, which is just noise
> > when there are obvious, basic problems. 'b4 diff' shows no actual
> > difference from v8 and v9, which should have been caught by a simple
> > build test right before 'git send-email'.
> >
> >>   KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> >> -else
> >> -CC_FLAGS_LTO        := -flto
> >> +endif
>
> The above patch has a guard CONFIG_LTO_CLANG_THIN, which can be removed.
> See llvm patch
>     https://github.com/llvm/llvm-project/pull/188074
> which supports distributed thin-lto mode too for reducing the number
> of renaming. In other words, for llvm23, both in-process and
> distributed-process are supported for thin-lto.
>
> >>   endif
> >>   CC_FLAGS_LTO       += -fvisibility=hidden
> >>
> >> @@ -1657,6 +1659,7 @@ endif # CONFIG_MODULES
> >>   CLEAN_FILES += vmlinux.symvers modules-only.symvers \
> >>             modules.builtin modules.builtin.modinfo modules.nsdeps \
> >>             modules.builtin.ranges vmlinux.o.map vmlinux.unstripped \
> >> +           vmlinux.thinlto-index builtin.order \
> >>             compile_commands.json rust/test \
> >>             rust-project.json .vmlinux.objs .vmlinux.export.c \
> >>                  .builtin-dtbs-list .builtin-dtb.S
> >> @@ -2118,7 +2121,7 @@ clean: $(clean-dirs)
> >>      $(call cmd,rmfiles)
> >>      @find . $(RCS_FIND_IGNORE) \
> >>              \( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
> >> -            -o -name '*.ko.*' \
> >> +            -o -name '*.ko.*' -o -name '*.o.thinlto.bc' \
> >>              -o -name '*.dtb' -o -name '*.dtbo' \
> >>              -o -name '*.dtb.S' -o -name '*.dtbo.S' \
> >>              -o -name '*.dt.yaml' -o -name 'dtbs-list' \
> > With that addressed above, the series survives my basic LLVM 22.1.2
> > build test with my distribution configuration. I'll provide formal tags
> > on a properly tested and fixed revision.
> >
> > Cheers,
> > Nathan
>

Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[Yonghong Song]

On 5/21/26 11:31 AM, Rong Xu wrote:
> Yonghong, thanks for the update.
>
> Regarding this guard: ther is a period of Clang (before this patch and
> after your first patch), even though ld.lld having these options
> (specifically --lto-whole-program-visibility -mllvm
> -always-rename-promoted-locals=false), distributed ThinLTO mode
> remains unsupported, correct? What the behvior of using this options
> in distributed mode with these compilers? nop or it will lead to
> error?

The in-process thin-lto support is landed on Feb 27.
The distributed thin-lto support is landed on Apr 24.

If people are using distributed thin-lto in kernel between Feb 27 and
Apr 24, there will be some issues. But people typically use released
compiler, so we should be fine.

>
> I would assume there will be errors; otherwise, you would not ask me
> to change my patch last time. In this case, I would keep this guard
> and remove it when the minimum llvm version passes llvm23. What do you
> think?

There is no need to keep compiler version guard.

Before llvm23, the below will be a noop:
    $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
since '-mllvm -always-rename-promoted-locals=false' is a new flag and the compiler won't
recognize it so the kernel will resolve above 'call ...' option as noop.

With llvm23 and later, the kernel will be able to recognize above options and
things should be okay.

>
> Best,
>
> -Rong
>
>
> On Thu, May 21, 2026 at 1:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>
>>
>> On 3/31/26 9:27 AM, Nathan Chancellor wrote:
>>> Hi Rong,
>>>
>>> On Tue, Mar 31, 2026 at 03:48:27PM +0000, xur@google.com wrote:
>>>> diff --git a/Makefile b/Makefile
>>>> index 69ccf9b8507d..26005c64016d 100644
>>>> --- a/Makefile
>>>> +++ b/Makefile
>>>> @@ -1047,11 +1047,13 @@ export CC_FLAGS_SCS
>>>>    endif
>>>>
>>>>    ifdef CONFIG_LTO_CLANG
>>>> -ifdef CONFIG_LTO_CLANG_THIN
>>>> +ifdef CONFIG_LTO_CLANG_FULL
>>>> +CC_FLAGS_LTO        := -flto
>>>> +else
>>>>    CC_FLAGS_LTO       := -flto=thin -fsplit-lto-unit
>>>> +if CONFIG_LTO_CLANG_THIN
>>> This should be an 'ifdef', not an 'if'. You copied Yonghong's mistake:
>>>
>>>     https://lore.kernel.org/abgRRX3PH9IaExi8@sirena.org.uk/
>>>     https://lore.kernel.org/6db3a2f6-d61c-42f1-9b9d-0aca021cc2d7@linux.dev/
>>>
>>> Please slow down and test build your changes before sending them. Each
>>> revision adds four new emails to everyone's inbox, which is just noise
>>> when there are obvious, basic problems. 'b4 diff' shows no actual
>>> difference from v8 and v9, which should have been caught by a simple
>>> build test right before 'git send-email'.
>>>
>>>>    KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
>>>> -else
>>>> -CC_FLAGS_LTO        := -flto
>>>> +endif
>> The above patch has a guard CONFIG_LTO_CLANG_THIN, which can be removed.
>> See llvm patch
>>      https://github.com/llvm/llvm-project/pull/188074
>> which supports distributed thin-lto mode too for reducing the number
>> of renaming. In other words, for llvm23, both in-process and
>> distributed-process are supported for thin-lto.
>>
>>>>    endif
>>>>    CC_FLAGS_LTO       += -fvisibility=hidden
>>>>
>>>> @@ -1657,6 +1659,7 @@ endif # CONFIG_MODULES
>>>>    CLEAN_FILES += vmlinux.symvers modules-only.symvers \
>>>>              modules.builtin modules.builtin.modinfo modules.nsdeps \
>>>>              modules.builtin.ranges vmlinux.o.map vmlinux.unstripped \
>>>> +           vmlinux.thinlto-index builtin.order \
>>>>              compile_commands.json rust/test \
>>>>              rust-project.json .vmlinux.objs .vmlinux.export.c \
>>>>                   .builtin-dtbs-list .builtin-dtb.S
>>>> @@ -2118,7 +2121,7 @@ clean: $(clean-dirs)
>>>>       $(call cmd,rmfiles)
>>>>       @find . $(RCS_FIND_IGNORE) \
>>>>               \( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
>>>> -            -o -name '*.ko.*' \
>>>> +            -o -name '*.ko.*' -o -name '*.o.thinlto.bc' \
>>>>               -o -name '*.dtb' -o -name '*.dtbo' \
>>>>               -o -name '*.dtb.S' -o -name '*.dtbo.S' \
>>>>               -o -name '*.dt.yaml' -o -name 'dtbs-list' \
>>> With that addressed above, the series survives my basic LLVM 22.1.2
>>> build test with my distribution configuration. I'll provide formal tags
>>> on a properly tested and fixed revision.
>>>
>>> Cheers,
>>> Nathan

Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[Rong Xu]

On Thu, May 21, 2026 at 2:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>
>
>
> On 5/21/26 11:31 AM, Rong Xu wrote:
> > Yonghong, thanks for the update.
> >
> > Regarding this guard: ther is a period of Clang (before this patch and
> > after your first patch), even though ld.lld having these options
> > (specifically --lto-whole-program-visibility -mllvm
> > -always-rename-promoted-locals=false), distributed ThinLTO mode
> > remains unsupported, correct? What the behvior of using this options
> > in distributed mode with these compilers? nop or it will lead to
> > error?
>
> The in-process thin-lto support is landed on Feb 27.
> The distributed thin-lto support is landed on Apr 24.
>
> If people are using distributed thin-lto in kernel between Feb 27 and
> Apr 24, there will be some issues. But people typically use released
> compiler, so we should be fine.

This is not the case for us (google). We do use compiler b/w releases,
and we build our own.

What is the issue if we use the compiler in b/w Feb27 and Apr24?

-Rong

>
> >
> > I would assume there will be errors; otherwise, you would not ask me
> > to change my patch last time. In this case, I would keep this guard
> > and remove it when the minimum llvm version passes llvm23. What do you
> > think?
>
> There is no need to keep compiler version guard.
>
> Before llvm23, the below will be a noop:
>     $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> since '-mllvm -always-rename-promoted-locals=false' is a new flag and the compiler won't
> recognize it so the kernel will resolve above 'call ...' option as noop.
>
> With llvm23 and later, the kernel will be able to recognize above options and
> things should be okay.
>
> >
> > Best,
> >
> > -Rong
> >
> >
> > On Thu, May 21, 2026 at 1:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
> >>
> >>
> >> On 3/31/26 9:27 AM, Nathan Chancellor wrote:
> >>> Hi Rong,
> >>>
> >>> On Tue, Mar 31, 2026 at 03:48:27PM +0000, xur@google.com wrote:
> >>>> diff --git a/Makefile b/Makefile
> >>>> index 69ccf9b8507d..26005c64016d 100644
> >>>> --- a/Makefile
> >>>> +++ b/Makefile
> >>>> @@ -1047,11 +1047,13 @@ export CC_FLAGS_SCS
> >>>>    endif
> >>>>
> >>>>    ifdef CONFIG_LTO_CLANG
> >>>> -ifdef CONFIG_LTO_CLANG_THIN
> >>>> +ifdef CONFIG_LTO_CLANG_FULL
> >>>> +CC_FLAGS_LTO        := -flto
> >>>> +else
> >>>>    CC_FLAGS_LTO       := -flto=thin -fsplit-lto-unit
> >>>> +if CONFIG_LTO_CLANG_THIN
> >>> This should be an 'ifdef', not an 'if'. You copied Yonghong's mistake:
> >>>
> >>>     https://lore.kernel.org/abgRRX3PH9IaExi8@sirena.org.uk/
> >>>     https://lore.kernel.org/6db3a2f6-d61c-42f1-9b9d-0aca021cc2d7@linux.dev/
> >>>
> >>> Please slow down and test build your changes before sending them. Each
> >>> revision adds four new emails to everyone's inbox, which is just noise
> >>> when there are obvious, basic problems. 'b4 diff' shows no actual
> >>> difference from v8 and v9, which should have been caught by a simple
> >>> build test right before 'git send-email'.
> >>>
> >>>>    KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> >>>> -else
> >>>> -CC_FLAGS_LTO        := -flto
> >>>> +endif
> >> The above patch has a guard CONFIG_LTO_CLANG_THIN, which can be removed.
> >> See llvm patch
> >>      https://github.com/llvm/llvm-project/pull/188074
> >> which supports distributed thin-lto mode too for reducing the number
> >> of renaming. In other words, for llvm23, both in-process and
> >> distributed-process are supported for thin-lto.
> >>
> >>>>    endif
> >>>>    CC_FLAGS_LTO       += -fvisibility=hidden
> >>>>
> >>>> @@ -1657,6 +1659,7 @@ endif # CONFIG_MODULES
> >>>>    CLEAN_FILES += vmlinux.symvers modules-only.symvers \
> >>>>              modules.builtin modules.builtin.modinfo modules.nsdeps \
> >>>>              modules.builtin.ranges vmlinux.o.map vmlinux.unstripped \
> >>>> +           vmlinux.thinlto-index builtin.order \
> >>>>              compile_commands.json rust/test \
> >>>>              rust-project.json .vmlinux.objs .vmlinux.export.c \
> >>>>                   .builtin-dtbs-list .builtin-dtb.S
> >>>> @@ -2118,7 +2121,7 @@ clean: $(clean-dirs)
> >>>>       $(call cmd,rmfiles)
> >>>>       @find . $(RCS_FIND_IGNORE) \
> >>>>               \( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
> >>>> -            -o -name '*.ko.*' \
> >>>> +            -o -name '*.ko.*' -o -name '*.o.thinlto.bc' \
> >>>>               -o -name '*.dtb' -o -name '*.dtbo' \
> >>>>               -o -name '*.dtb.S' -o -name '*.dtbo.S' \
> >>>>               -o -name '*.dt.yaml' -o -name 'dtbs-list' \
> >>> With that addressed above, the series survives my basic LLVM 22.1.2
> >>> build test with my distribution configuration. I'll provide formal tags
> >>> on a properly tested and fixed revision.
> >>>
> >>> Cheers,
> >>> Nathan
>

Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[Yonghong Song]

On 5/22/26 8:32 AM, Rong Xu wrote:
> On Thu, May 21, 2026 at 2:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>
>>
>> On 5/21/26 11:31 AM, Rong Xu wrote:
>>> Yonghong, thanks for the update.
>>>
>>> Regarding this guard: ther is a period of Clang (before this patch and
>>> after your first patch), even though ld.lld having these options
>>> (specifically --lto-whole-program-visibility -mllvm
>>> -always-rename-promoted-locals=false), distributed ThinLTO mode
>>> remains unsupported, correct? What the behvior of using this options
>>> in distributed mode with these compilers? nop or it will lead to
>>> error?
>> The in-process thin-lto support is landed on Feb 27.
>> The distributed thin-lto support is landed on Apr 24.
>>
>> If people are using distributed thin-lto in kernel between Feb 27 and
>> Apr 24, there will be some issues. But people typically use released
>> compiler, so we should be fine.
> This is not the case for us (google). We do use compiler b/w releases,
> and we build our own.
>
> What is the issue if we use the compiler in b/w Feb27 and Apr24?

If you use the custom compiler between Feb27 and Apr24 and your kernel
will do distributed thin-lto, you can remove
    $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
from your kernel. Since you have custom compiler, you can
do some customization for your kernel as well.


>
> -Rong
>
>>> I would assume there will be errors; otherwise, you would not ask me
>>> to change my patch last time. In this case, I would keep this guard
>>> and remove it when the minimum llvm version passes llvm23. What do you
>>> think?
>> There is no need to keep compiler version guard.
>>
>> Before llvm23, the below will be a noop:
>>      $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
>> since '-mllvm -always-rename-promoted-locals=false' is a new flag and the compiler won't
>> recognize it so the kernel will resolve above 'call ...' option as noop.
>>
>> With llvm23 and later, the kernel will be able to recognize above options and
>> things should be okay.
>>
>>> Best,
>>>
>>> -Rong
>>>
>>>
>>> On Thu, May 21, 2026 at 1:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>>>
>>>> On 3/31/26 9:27 AM, Nathan Chancellor wrote:
>>>>> Hi Rong,
>>>>>
>>>>> On Tue, Mar 31, 2026 at 03:48:27PM +0000, xur@google.com wrote:
>>>>>> diff --git a/Makefile b/Makefile
>>>>>> index 69ccf9b8507d..26005c64016d 100644
>>>>>> --- a/Makefile
>>>>>> +++ b/Makefile
>>>>>> @@ -1047,11 +1047,13 @@ export CC_FLAGS_SCS
>>>>>>     endif
>>>>>>
>>>>>>     ifdef CONFIG_LTO_CLANG
>>>>>> -ifdef CONFIG_LTO_CLANG_THIN
>>>>>> +ifdef CONFIG_LTO_CLANG_FULL
>>>>>> +CC_FLAGS_LTO        := -flto
>>>>>> +else
>>>>>>     CC_FLAGS_LTO       := -flto=thin -fsplit-lto-unit
>>>>>> +if CONFIG_LTO_CLANG_THIN
>>>>> This should be an 'ifdef', not an 'if'. You copied Yonghong's mistake:
>>>>>
>>>>>      https://lore.kernel.org/abgRRX3PH9IaExi8@sirena.org.uk/
>>>>>      https://lore.kernel.org/6db3a2f6-d61c-42f1-9b9d-0aca021cc2d7@linux.dev/
>>>>>
>>>>> Please slow down and test build your changes before sending them. Each
>>>>> revision adds four new emails to everyone's inbox, which is just noise
>>>>> when there are obvious, basic problems. 'b4 diff' shows no actual
>>>>> difference from v8 and v9, which should have been caught by a simple
>>>>> build test right before 'git send-email'.
>>>>>
>>>>>>     KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
>>>>>> -else
>>>>>> -CC_FLAGS_LTO        := -flto
>>>>>> +endif
>>>> The above patch has a guard CONFIG_LTO_CLANG_THIN, which can be removed.
>>>> See llvm patch
>>>>       https://github.com/llvm/llvm-project/pull/188074
>>>> which supports distributed thin-lto mode too for reducing the number
>>>> of renaming. In other words, for llvm23, both in-process and
>>>> distributed-process are supported for thin-lto.
>>>>
>>>>>>     endif
>>>>>>     CC_FLAGS_LTO       += -fvisibility=hidden
>>>>>>
>>>>>> @@ -1657,6 +1659,7 @@ endif # CONFIG_MODULES
>>>>>>     CLEAN_FILES += vmlinux.symvers modules-only.symvers \
>>>>>>               modules.builtin modules.builtin.modinfo modules.nsdeps \
>>>>>>               modules.builtin.ranges vmlinux.o.map vmlinux.unstripped \
>>>>>> +           vmlinux.thinlto-index builtin.order \
>>>>>>               compile_commands.json rust/test \
>>>>>>               rust-project.json .vmlinux.objs .vmlinux.export.c \
>>>>>>                    .builtin-dtbs-list .builtin-dtb.S
>>>>>> @@ -2118,7 +2121,7 @@ clean: $(clean-dirs)
>>>>>>        $(call cmd,rmfiles)
>>>>>>        @find . $(RCS_FIND_IGNORE) \
>>>>>>                \( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
>>>>>> -            -o -name '*.ko.*' \
>>>>>> +            -o -name '*.ko.*' -o -name '*.o.thinlto.bc' \
>>>>>>                -o -name '*.dtb' -o -name '*.dtbo' \
>>>>>>                -o -name '*.dtb.S' -o -name '*.dtbo.S' \
>>>>>>                -o -name '*.dt.yaml' -o -name 'dtbs-list' \
>>>>> With that addressed above, the series survives my basic LLVM 22.1.2
>>>>> build test with my distribution configuration. I'll provide formal tags
>>>>> on a properly tested and fixed revision.
>>>>>
>>>>> Cheers,
>>>>> Nathan

Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[Rong Xu]

On Fri, May 22, 2026 at 10:52 AM Yonghong Song <yonghong.song@linux.dev> wrote:
>
>
>
> On 5/22/26 8:32 AM, Rong Xu wrote:
> > On Thu, May 21, 2026 at 2:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
> >>
> >>
> >> On 5/21/26 11:31 AM, Rong Xu wrote:
> >>> Yonghong, thanks for the update.
> >>>
> >>> Regarding this guard: ther is a period of Clang (before this patch and
> >>> after your first patch), even though ld.lld having these options
> >>> (specifically --lto-whole-program-visibility -mllvm
> >>> -always-rename-promoted-locals=false), distributed ThinLTO mode
> >>> remains unsupported, correct? What the behvior of using this options
> >>> in distributed mode with these compilers? nop or it will lead to
> >>> error?
> >> The in-process thin-lto support is landed on Feb 27.
> >> The distributed thin-lto support is landed on Apr 24.
> >>
> >> If people are using distributed thin-lto in kernel between Feb 27 and
> >> Apr 24, there will be some issues. But people typically use released
> >> compiler, so we should be fine.
> > This is not the case for us (google). We do use compiler b/w releases,
> > and we build our own.
> >
> > What is the issue if we use the compiler in b/w Feb27 and Apr24?
>
> If you use the custom compiler between Feb27 and Apr24 and your kernel
> will do distributed thin-lto, you can remove
>     $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> from your kernel. Since you have custom compiler, you can
> do some customization for your kernel as well.

I am referring to this specific patch -- there are cases that use
custom compilers built between the February 27 and April 24 LLVM
releases.
I don't want to see any breakage for distributed ThinLTO in these cases.

I would prefer to keep this guard for distributed ThinLTO for the time
being and remove it later. What do you think?


>
>
> >
> > -Rong
> >
> >>> I would assume there will be errors; otherwise, you would not ask me
> >>> to change my patch last time. In this case, I would keep this guard
> >>> and remove it when the minimum llvm version passes llvm23. What do you
> >>> think?
> >> There is no need to keep compiler version guard.
> >>
> >> Before llvm23, the below will be a noop:
> >>      $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> >> since '-mllvm -always-rename-promoted-locals=false' is a new flag and the compiler won't
> >> recognize it so the kernel will resolve above 'call ...' option as noop.
> >>
> >> With llvm23 and later, the kernel will be able to recognize above options and
> >> things should be okay.
> >>
> >>> Best,
> >>>
> >>> -Rong
> >>>
> >>>
> >>> On Thu, May 21, 2026 at 1:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
> >>>>
> >>>> On 3/31/26 9:27 AM, Nathan Chancellor wrote:
> >>>>> Hi Rong,
> >>>>>
> >>>>> On Tue, Mar 31, 2026 at 03:48:27PM +0000, xur@google.com wrote:
> >>>>>> diff --git a/Makefile b/Makefile
> >>>>>> index 69ccf9b8507d..26005c64016d 100644
> >>>>>> --- a/Makefile
> >>>>>> +++ b/Makefile
> >>>>>> @@ -1047,11 +1047,13 @@ export CC_FLAGS_SCS
> >>>>>>     endif
> >>>>>>
> >>>>>>     ifdef CONFIG_LTO_CLANG
> >>>>>> -ifdef CONFIG_LTO_CLANG_THIN
> >>>>>> +ifdef CONFIG_LTO_CLANG_FULL
> >>>>>> +CC_FLAGS_LTO        := -flto
> >>>>>> +else
> >>>>>>     CC_FLAGS_LTO       := -flto=thin -fsplit-lto-unit
> >>>>>> +if CONFIG_LTO_CLANG_THIN
> >>>>> This should be an 'ifdef', not an 'if'. You copied Yonghong's mistake:
> >>>>>
> >>>>>      https://lore.kernel.org/abgRRX3PH9IaExi8@sirena.org.uk/
> >>>>>      https://lore.kernel.org/6db3a2f6-d61c-42f1-9b9d-0aca021cc2d7@linux.dev/
> >>>>>
> >>>>> Please slow down and test build your changes before sending them. Each
> >>>>> revision adds four new emails to everyone's inbox, which is just noise
> >>>>> when there are obvious, basic problems. 'b4 diff' shows no actual
> >>>>> difference from v8 and v9, which should have been caught by a simple
> >>>>> build test right before 'git send-email'.
> >>>>>
> >>>>>>     KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> >>>>>> -else
> >>>>>> -CC_FLAGS_LTO        := -flto
> >>>>>> +endif
> >>>> The above patch has a guard CONFIG_LTO_CLANG_THIN, which can be removed.
> >>>> See llvm patch
> >>>>       https://github.com/llvm/llvm-project/pull/188074
> >>>> which supports distributed thin-lto mode too for reducing the number
> >>>> of renaming. In other words, for llvm23, both in-process and
> >>>> distributed-process are supported for thin-lto.
> >>>>
> >>>>>>     endif
> >>>>>>     CC_FLAGS_LTO       += -fvisibility=hidden
> >>>>>>
> >>>>>> @@ -1657,6 +1659,7 @@ endif # CONFIG_MODULES
> >>>>>>     CLEAN_FILES += vmlinux.symvers modules-only.symvers \
> >>>>>>               modules.builtin modules.builtin.modinfo modules.nsdeps \
> >>>>>>               modules.builtin.ranges vmlinux.o.map vmlinux.unstripped \
> >>>>>> +           vmlinux.thinlto-index builtin.order \
> >>>>>>               compile_commands.json rust/test \
> >>>>>>               rust-project.json .vmlinux.objs .vmlinux.export.c \
> >>>>>>                    .builtin-dtbs-list .builtin-dtb.S
> >>>>>> @@ -2118,7 +2121,7 @@ clean: $(clean-dirs)
> >>>>>>        $(call cmd,rmfiles)
> >>>>>>        @find . $(RCS_FIND_IGNORE) \
> >>>>>>                \( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
> >>>>>> -            -o -name '*.ko.*' \
> >>>>>> +            -o -name '*.ko.*' -o -name '*.o.thinlto.bc' \
> >>>>>>                -o -name '*.dtb' -o -name '*.dtbo' \
> >>>>>>                -o -name '*.dtb.S' -o -name '*.dtbo.S' \
> >>>>>>                -o -name '*.dt.yaml' -o -name 'dtbs-list' \
> >>>>> With that addressed above, the series survives my basic LLVM 22.1.2
> >>>>> build test with my distribution configuration. I'll provide formal tags
> >>>>> on a properly tested and fixed revision.
> >>>>>
> >>>>> Cheers,
> >>>>> Nathan
>

Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[Yonghong Song]

On 5/22/26 11:14 AM, Rong Xu wrote:
> On Fri, May 22, 2026 at 10:52 AM Yonghong Song <yonghong.song@linux.dev> wrote:
>>
>>
>> On 5/22/26 8:32 AM, Rong Xu wrote:
>>> On Thu, May 21, 2026 at 2:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>>>
>>>> On 5/21/26 11:31 AM, Rong Xu wrote:
>>>>> Yonghong, thanks for the update.
>>>>>
>>>>> Regarding this guard: ther is a period of Clang (before this patch and
>>>>> after your first patch), even though ld.lld having these options
>>>>> (specifically --lto-whole-program-visibility -mllvm
>>>>> -always-rename-promoted-locals=false), distributed ThinLTO mode
>>>>> remains unsupported, correct? What the behvior of using this options
>>>>> in distributed mode with these compilers? nop or it will lead to
>>>>> error?
>>>> The in-process thin-lto support is landed on Feb 27.
>>>> The distributed thin-lto support is landed on Apr 24.
>>>>
>>>> If people are using distributed thin-lto in kernel between Feb 27 and
>>>> Apr 24, there will be some issues. But people typically use released
>>>> compiler, so we should be fine.
>>> This is not the case for us (google). We do use compiler b/w releases,
>>> and we build our own.
>>>
>>> What is the issue if we use the compiler in b/w Feb27 and Apr24?
>> If you use the custom compiler between Feb27 and Apr24 and your kernel
>> will do distributed thin-lto, you can remove
>>      $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
>> from your kernel. Since you have custom compiler, you can
>> do some customization for your kernel as well.
> I am referring to this specific patch -- there are cases that use
> custom compilers built between the February 27 and April 24 LLVM
> releases.
> I don't want to see any breakage for distributed ThinLTO in these cases.
>
> I would prefer to keep this guard for distributed ThinLTO for the time
> being and remove it later. What do you think?

For 'remove it later', when this will happen? When llvm23 cuts the rc
in July or cut the release in September or the end of bug fix say in December?
If we carry the guard (for distributed thinlto) in this kernel release,
that means at some point, we will need to do kernel backport, extra work.
Also, since you are building custom in-development compiler, you can
disable this flag -always-rename-promoted-locals, problem solved, right?

Nathan, what do you think?
  

>
>
>>
>>> -Rong
>>>
>>>>> I would assume there will be errors; otherwise, you would not ask me
>>>>> to change my patch last time. In this case, I would keep this guard
>>>>> and remove it when the minimum llvm version passes llvm23. What do you
>>>>> think?
>>>> There is no need to keep compiler version guard.
>>>>
>>>> Before llvm23, the below will be a noop:
>>>>       $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
>>>> since '-mllvm -always-rename-promoted-locals=false' is a new flag and the compiler won't
>>>> recognize it so the kernel will resolve above 'call ...' option as noop.
>>>>
>>>> With llvm23 and later, the kernel will be able to recognize above options and
>>>> things should be okay.
>>>>
>>>>> Best,
>>>>>
>>>>> -Rong
>>>>>
>>>>>
>>>>> On Thu, May 21, 2026 at 1:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>>>>> On 3/31/26 9:27 AM, Nathan Chancellor wrote:
>>>>>>> Hi Rong,
>>>>>>>
>>>>>>> On Tue, Mar 31, 2026 at 03:48:27PM +0000, xur@google.com wrote:
>>>>>>>> diff --git a/Makefile b/Makefile
>>>>>>>> index 69ccf9b8507d..26005c64016d 100644
>>>>>>>> --- a/Makefile
>>>>>>>> +++ b/Makefile
>>>>>>>> @@ -1047,11 +1047,13 @@ export CC_FLAGS_SCS
>>>>>>>>      endif
>>>>>>>>
>>>>>>>>      ifdef CONFIG_LTO_CLANG
>>>>>>>> -ifdef CONFIG_LTO_CLANG_THIN
>>>>>>>> +ifdef CONFIG_LTO_CLANG_FULL
>>>>>>>> +CC_FLAGS_LTO        := -flto
>>>>>>>> +else
>>>>>>>>      CC_FLAGS_LTO       := -flto=thin -fsplit-lto-unit
>>>>>>>> +if CONFIG_LTO_CLANG_THIN
>>>>>>> This should be an 'ifdef', not an 'if'. You copied Yonghong's mistake:
>>>>>>>
>>>>>>>       https://lore.kernel.org/abgRRX3PH9IaExi8@sirena.org.uk/
>>>>>>>       https://lore.kernel.org/6db3a2f6-d61c-42f1-9b9d-0aca021cc2d7@linux.dev/
>>>>>>>
>>>>>>> Please slow down and test build your changes before sending them. Each
>>>>>>> revision adds four new emails to everyone's inbox, which is just noise
>>>>>>> when there are obvious, basic problems. 'b4 diff' shows no actual
>>>>>>> difference from v8 and v9, which should have been caught by a simple
>>>>>>> build test right before 'git send-email'.
>>>>>>>
>>>>>>>>      KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
>>>>>>>> -else
>>>>>>>> -CC_FLAGS_LTO        := -flto
>>>>>>>> +endif
>>>>>> The above patch has a guard CONFIG_LTO_CLANG_THIN, which can be removed.
>>>>>> See llvm patch
>>>>>>        https://github.com/llvm/llvm-project/pull/188074
>>>>>> which supports distributed thin-lto mode too for reducing the number
>>>>>> of renaming. In other words, for llvm23, both in-process and
>>>>>> distributed-process are supported for thin-lto.
>>>>>>
>>>>>>>>      endif
>>>>>>>>      CC_FLAGS_LTO       += -fvisibility=hidden
>>>>>>>>
>>>>>>>> @@ -1657,6 +1659,7 @@ endif # CONFIG_MODULES
>>>>>>>>      CLEAN_FILES += vmlinux.symvers modules-only.symvers \
>>>>>>>>                modules.builtin modules.builtin.modinfo modules.nsdeps \
>>>>>>>>                modules.builtin.ranges vmlinux.o.map vmlinux.unstripped \
>>>>>>>> +           vmlinux.thinlto-index builtin.order \
>>>>>>>>                compile_commands.json rust/test \
>>>>>>>>                rust-project.json .vmlinux.objs .vmlinux.export.c \
>>>>>>>>                     .builtin-dtbs-list .builtin-dtb.S
>>>>>>>> @@ -2118,7 +2121,7 @@ clean: $(clean-dirs)
>>>>>>>>         $(call cmd,rmfiles)
>>>>>>>>         @find . $(RCS_FIND_IGNORE) \
>>>>>>>>                 \( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
>>>>>>>> -            -o -name '*.ko.*' \
>>>>>>>> +            -o -name '*.ko.*' -o -name '*.o.thinlto.bc' \
>>>>>>>>                 -o -name '*.dtb' -o -name '*.dtbo' \
>>>>>>>>                 -o -name '*.dtb.S' -o -name '*.dtbo.S' \
>>>>>>>>                 -o -name '*.dt.yaml' -o -name 'dtbs-list' \
>>>>>>> With that addressed above, the series survives my basic LLVM 22.1.2
>>>>>>> build test with my distribution configuration. I'll provide formal tags
>>>>>>> on a properly tested and fixed revision.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Nathan

Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[Rong Xu]

On Fri, May 22, 2026 at 11:44 AM Yonghong Song <yonghong.song@linux.dev> wrote:
>
>
>
> On 5/22/26 11:14 AM, Rong Xu wrote:
> > On Fri, May 22, 2026 at 10:52 AM Yonghong Song <yonghong.song@linux.dev> wrote:
> >>
> >>
> >> On 5/22/26 8:32 AM, Rong Xu wrote:
> >>> On Thu, May 21, 2026 at 2:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
> >>>>
> >>>> On 5/21/26 11:31 AM, Rong Xu wrote:
> >>>>> Yonghong, thanks for the update.
> >>>>>
> >>>>> Regarding this guard: ther is a period of Clang (before this patch and
> >>>>> after your first patch), even though ld.lld having these options
> >>>>> (specifically --lto-whole-program-visibility -mllvm
> >>>>> -always-rename-promoted-locals=false), distributed ThinLTO mode
> >>>>> remains unsupported, correct? What the behvior of using this options
> >>>>> in distributed mode with these compilers? nop or it will lead to
> >>>>> error?
> >>>> The in-process thin-lto support is landed on Feb 27.
> >>>> The distributed thin-lto support is landed on Apr 24.
> >>>>
> >>>> If people are using distributed thin-lto in kernel between Feb 27 and
> >>>> Apr 24, there will be some issues. But people typically use released
> >>>> compiler, so we should be fine.
> >>> This is not the case for us (google). We do use compiler b/w releases,
> >>> and we build our own.
> >>>
> >>> What is the issue if we use the compiler in b/w Feb27 and Apr24?
> >> If you use the custom compiler between Feb27 and Apr24 and your kernel
> >> will do distributed thin-lto, you can remove
> >>      $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> >> from your kernel. Since you have custom compiler, you can
> >> do some customization for your kernel as well.
> > I am referring to this specific patch -- there are cases that use
> > custom compilers built between the February 27 and April 24 LLVM
> > releases.
> > I don't want to see any breakage for distributed ThinLTO in these cases.
> >
> > I would prefer to keep this guard for distributed ThinLTO for the time
> > being and remove it later. What do you think?
>
> For 'remove it later', when this will happen? When llvm23 cuts the rc
> in July or cut the release in September or the end of bug fix say in December?

I can remove the guard when the minimal clang containis the 4/24 patch.

> If we carry the guard (for distributed thinlto) in this kernel release,
> that means at some point, we will need to do kernel backport, extra work.

I don't understand here: this is part of the distributed thinlto patch
that you would need merge anyay.
where is the extra work for backporting?

> Also, since you are building custom in-development compiler, you can
> disable this flag -always-rename-promoted-locals, problem solved, right?

I'm not only talking about me. There are other users also use this way.
BTW, even in google, I don't control the compiler that being used.

>
> Nathan, what do you think?
>
>
> >
> >
> >>
> >>> -Rong
> >>>
> >>>>> I would assume there will be errors; otherwise, you would not ask me
> >>>>> to change my patch last time. In this case, I would keep this guard
> >>>>> and remove it when the minimum llvm version passes llvm23. What do you
> >>>>> think?
> >>>> There is no need to keep compiler version guard.
> >>>>
> >>>> Before llvm23, the below will be a noop:
> >>>>       $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> >>>> since '-mllvm -always-rename-promoted-locals=false' is a new flag and the compiler won't
> >>>> recognize it so the kernel will resolve above 'call ...' option as noop.
> >>>>
> >>>> With llvm23 and later, the kernel will be able to recognize above options and
> >>>> things should be okay.
> >>>>
> >>>>> Best,
> >>>>>
> >>>>> -Rong
> >>>>>
> >>>>>
> >>>>> On Thu, May 21, 2026 at 1:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
> >>>>>> On 3/31/26 9:27 AM, Nathan Chancellor wrote:
> >>>>>>> Hi Rong,
> >>>>>>>
> >>>>>>> On Tue, Mar 31, 2026 at 03:48:27PM +0000, xur@google.com wrote:
> >>>>>>>> diff --git a/Makefile b/Makefile
> >>>>>>>> index 69ccf9b8507d..26005c64016d 100644
> >>>>>>>> --- a/Makefile
> >>>>>>>> +++ b/Makefile
> >>>>>>>> @@ -1047,11 +1047,13 @@ export CC_FLAGS_SCS
> >>>>>>>>      endif
> >>>>>>>>
> >>>>>>>>      ifdef CONFIG_LTO_CLANG
> >>>>>>>> -ifdef CONFIG_LTO_CLANG_THIN
> >>>>>>>> +ifdef CONFIG_LTO_CLANG_FULL
> >>>>>>>> +CC_FLAGS_LTO        := -flto
> >>>>>>>> +else
> >>>>>>>>      CC_FLAGS_LTO       := -flto=thin -fsplit-lto-unit
> >>>>>>>> +if CONFIG_LTO_CLANG_THIN
> >>>>>>> This should be an 'ifdef', not an 'if'. You copied Yonghong's mistake:
> >>>>>>>
> >>>>>>>       https://lore.kernel.org/abgRRX3PH9IaExi8@sirena.org.uk/
> >>>>>>>       https://lore.kernel.org/6db3a2f6-d61c-42f1-9b9d-0aca021cc2d7@linux.dev/
> >>>>>>>
> >>>>>>> Please slow down and test build your changes before sending them. Each
> >>>>>>> revision adds four new emails to everyone's inbox, which is just noise
> >>>>>>> when there are obvious, basic problems. 'b4 diff' shows no actual
> >>>>>>> difference from v8 and v9, which should have been caught by a simple
> >>>>>>> build test right before 'git send-email'.
> >>>>>>>
> >>>>>>>>      KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> >>>>>>>> -else
> >>>>>>>> -CC_FLAGS_LTO        := -flto
> >>>>>>>> +endif
> >>>>>> The above patch has a guard CONFIG_LTO_CLANG_THIN, which can be removed.
> >>>>>> See llvm patch
> >>>>>>        https://github.com/llvm/llvm-project/pull/188074
> >>>>>> which supports distributed thin-lto mode too for reducing the number
> >>>>>> of renaming. In other words, for llvm23, both in-process and
> >>>>>> distributed-process are supported for thin-lto.
> >>>>>>
> >>>>>>>>      endif
> >>>>>>>>      CC_FLAGS_LTO       += -fvisibility=hidden
> >>>>>>>>
> >>>>>>>> @@ -1657,6 +1659,7 @@ endif # CONFIG_MODULES
> >>>>>>>>      CLEAN_FILES += vmlinux.symvers modules-only.symvers \
> >>>>>>>>                modules.builtin modules.builtin.modinfo modules.nsdeps \
> >>>>>>>>                modules.builtin.ranges vmlinux.o.map vmlinux.unstripped \
> >>>>>>>> +           vmlinux.thinlto-index builtin.order \
> >>>>>>>>                compile_commands.json rust/test \
> >>>>>>>>                rust-project.json .vmlinux.objs .vmlinux.export.c \
> >>>>>>>>                     .builtin-dtbs-list .builtin-dtb.S
> >>>>>>>> @@ -2118,7 +2121,7 @@ clean: $(clean-dirs)
> >>>>>>>>         $(call cmd,rmfiles)
> >>>>>>>>         @find . $(RCS_FIND_IGNORE) \
> >>>>>>>>                 \( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
> >>>>>>>> -            -o -name '*.ko.*' \
> >>>>>>>> +            -o -name '*.ko.*' -o -name '*.o.thinlto.bc' \
> >>>>>>>>                 -o -name '*.dtb' -o -name '*.dtbo' \
> >>>>>>>>                 -o -name '*.dtb.S' -o -name '*.dtbo.S' \
> >>>>>>>>                 -o -name '*.dt.yaml' -o -name 'dtbs-list' \
> >>>>>>> With that addressed above, the series survives my basic LLVM 22.1.2
> >>>>>>> build test with my distribution configuration. I'll provide formal tags
> >>>>>>> on a properly tested and fixed revision.
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Nathan
>

Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[Nathan Chancellor]

On Fri, May 22, 2026 at 11:58:35AM -0700, Rong Xu wrote:
> On Fri, May 22, 2026 at 11:44 AM Yonghong Song <yonghong.song@linux.dev> wrote:
> > On 5/22/26 11:14 AM, Rong Xu wrote:
> > > On Fri, May 22, 2026 at 10:52 AM Yonghong Song <yonghong.song@linux.dev> wrote:
> > >> On 5/22/26 8:32 AM, Rong Xu wrote:
> > >>> On Thu, May 21, 2026 at 2:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
> > >>>>
> > >>>> On 5/21/26 11:31 AM, Rong Xu wrote:
> > >>>>> Yonghong, thanks for the update.
> > >>>>>
> > >>>>> Regarding this guard: ther is a period of Clang (before this patch and
> > >>>>> after your first patch), even though ld.lld having these options
> > >>>>> (specifically --lto-whole-program-visibility -mllvm
> > >>>>> -always-rename-promoted-locals=false), distributed ThinLTO mode
> > >>>>> remains unsupported, correct? What the behvior of using this options
> > >>>>> in distributed mode with these compilers? nop or it will lead to
> > >>>>> error?
> > >>>> The in-process thin-lto support is landed on Feb 27.
> > >>>> The distributed thin-lto support is landed on Apr 24.
> > >>>>
> > >>>> If people are using distributed thin-lto in kernel between Feb 27 and
> > >>>> Apr 24, there will be some issues. But people typically use released
> > >>>> compiler, so we should be fine.
> > >>> This is not the case for us (google). We do use compiler b/w releases,
> > >>> and we build our own.
> > >>>
> > >>> What is the issue if we use the compiler in b/w Feb27 and Apr24?
> > >> If you use the custom compiler between Feb27 and Apr24 and your kernel
> > >> will do distributed thin-lto, you can remove
> > >>      $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> > >> from your kernel. Since you have custom compiler, you can
> > >> do some customization for your kernel as well.
> > > I am referring to this specific patch -- there are cases that use
> > > custom compilers built between the February 27 and April 24 LLVM
> > > releases.
> > > I don't want to see any breakage for distributed ThinLTO in these cases.
> > >
> > > I would prefer to keep this guard for distributed ThinLTO for the time
> > > being and remove it later. What do you think?
> >
> > For 'remove it later', when this will happen? When llvm23 cuts the rc
> > in July or cut the release in September or the end of bug fix say in December?
> 
> I can remove the guard when the minimal clang containis the 4/24 patch.

I think we could just change

  ifdef CONFIG_LTO_CLANG_THIN
  KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
  endif

to

  ifneq ($(CONFIG_LTO_CLANG_THIN)$(CONFIG_LTO_CLANG_THIN_DIST),)
  KBUILD_LDFLAGS += $(if $(call clang-min-version,230100),--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
  endif

when LLVM 23.1.0-rc1 is out to avoid that Feb 27 to Apr 24 breakage?

> > If we carry the guard (for distributed thinlto) in this kernel release,
> > that means at some point, we will need to do kernel backport, extra work.
> 
> I don't understand here: this is part of the distributed thinlto patch
> that you would need merge anyay.
> where is the extra work for backporting?
> 
> > Also, since you are building custom in-development compiler, you can
> > disable this flag -always-rename-promoted-locals, problem solved, right?
> 
> I'm not only talking about me. There are other users also use this way.
> BTW, even in google, I don't control the compiler that being used.

So in general, we assume that folks who are using prerelease compilers
(i.e., 23.0.0 in this case) are upgrading them regularly, as we may need
to workaround or fix issues that happen in main that cannot be
dynamically detected (at least not easily or conveniently). For example,
recent main versions of clang have support for -Wattribute-alias, so we
need to turn it off via #pragmas like done for GCC, which will break
things for clang-23 versions that do not have -Wattribute-alias:

  https://git.kernel.org/nathan/c/bc5ffe737f56ee2734597069ed71f48830549483

So the argument about breaking compilers in between Feb 27 and Apr 24 is
not really relevant in my opinion since they should be short lived in
terms of deployment. However, given that things work the way the check
is currently written and the LLVM 23 branch is only a couple of months
away, I am fine with just sticking with how it is currently written and
updating it when things are more guaranteed to work.

-- 
Cheers,
Nathan

Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[Rong Xu]

Thanks Nathan for comments and suggestions. My comments are inlined.

On Fri, May 22, 2026 at 6:17 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> On Fri, May 22, 2026 at 11:58:35AM -0700, Rong Xu wrote:
> > On Fri, May 22, 2026 at 11:44 AM Yonghong Song <yonghong.song@linux.dev> wrote:
> > > On 5/22/26 11:14 AM, Rong Xu wrote:
> > > > On Fri, May 22, 2026 at 10:52 AM Yonghong Song <yonghong.song@linux.dev> wrote:
> > > >> On 5/22/26 8:32 AM, Rong Xu wrote:
> > > >>> On Thu, May 21, 2026 at 2:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
> > > >>>>
> > > >>>> On 5/21/26 11:31 AM, Rong Xu wrote:
> > > >>>>> Yonghong, thanks for the update.
> > > >>>>>
> > > >>>>> Regarding this guard: ther is a period of Clang (before this patch and
> > > >>>>> after your first patch), even though ld.lld having these options
> > > >>>>> (specifically --lto-whole-program-visibility -mllvm
> > > >>>>> -always-rename-promoted-locals=false), distributed ThinLTO mode
> > > >>>>> remains unsupported, correct? What the behvior of using this options
> > > >>>>> in distributed mode with these compilers? nop or it will lead to
> > > >>>>> error?
> > > >>>> The in-process thin-lto support is landed on Feb 27.
> > > >>>> The distributed thin-lto support is landed on Apr 24.
> > > >>>>
> > > >>>> If people are using distributed thin-lto in kernel between Feb 27 and
> > > >>>> Apr 24, there will be some issues. But people typically use released
> > > >>>> compiler, so we should be fine.
> > > >>> This is not the case for us (google). We do use compiler b/w releases,
> > > >>> and we build our own.
> > > >>>
> > > >>> What is the issue if we use the compiler in b/w Feb27 and Apr24?
> > > >> If you use the custom compiler between Feb27 and Apr24 and your kernel
> > > >> will do distributed thin-lto, you can remove
> > > >>      $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> > > >> from your kernel. Since you have custom compiler, you can
> > > >> do some customization for your kernel as well.
> > > > I am referring to this specific patch -- there are cases that use
> > > > custom compilers built between the February 27 and April 24 LLVM
> > > > releases.
> > > > I don't want to see any breakage for distributed ThinLTO in these cases.
> > > >
> > > > I would prefer to keep this guard for distributed ThinLTO for the time
> > > > being and remove it later. What do you think?
> > >
> > > For 'remove it later', when this will happen? When llvm23 cuts the rc
> > > in July or cut the release in September or the end of bug fix say in December?
> >
> > I can remove the guard when the minimal clang containis the 4/24 patch.
>
> I think we could just change
>
>   ifdef CONFIG_LTO_CLANG_THIN
>   KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
>   endif
>
> to
>
>   ifneq ($(CONFIG_LTO_CLANG_THIN)$(CONFIG_LTO_CLANG_THIN_DIST),)
>   KBUILD_LDFLAGS += $(if $(call clang-min-version,230100),--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
>   endif
>
> when LLVM 23.1.0-rc1 is out to avoid that Feb 27 to Apr 24 breakage?

I don't understand why we need this new "ifneq ..." guard. We have
already checked CONFIG_LTO_CLANG=y, and CONFIG_LTO_CLANG_FULL != y.
I think this "ifnef ..." will always be true (so redundant).

>
> > > If we carry the guard (for distributed thinlto) in this kernel release,
> > > that means at some point, we will need to do kernel backport, extra work.
> >
> > I don't understand here: this is part of the distributed thinlto patch
> > that you would need merge anyay.
> > where is the extra work for backporting?
> >
> > > Also, since you are building custom in-development compiler, you can
> > > disable this flag -always-rename-promoted-locals, problem solved, right?
> >
> > I'm not only talking about me. There are other users also use this way.
> > BTW, even in google, I don't control the compiler that being used.
>
> So in general, we assume that folks who are using prerelease compilers
> (i.e., 23.0.0 in this case) are upgrading them regularly, as we may need
> to workaround or fix issues that happen in main that cannot be
> dynamically detected (at least not easily or conveniently). For example,
> recent main versions of clang have support for -Wattribute-alias, so we
> need to turn it off via #pragmas like done for GCC, which will break
> things for clang-23 versions that do not have -Wattribute-alias:
>
>   https://git.kernel.org/nathan/c/bc5ffe737f56ee2734597069ed71f48830549483
>
> So the argument about breaking compilers in between Feb 27 and Apr 24 is
> not really relevant in my opinion since they should be short lived in
> terms of deployment. However, given that things work the way the check
> is currently written and the LLVM 23 branch is only a couple of months
> away, I am fine with just sticking with how it is currently written and
> updating it when things are more guaranteed to work.

This works for me. I can add a comment here.
Like the following:
=====
 ifdef CONFIG_LTO_CLANG
-ifdef CONFIG_LTO_CLANG_THIN
+ifdef CONFIG_LTO_CLANG_FULL
+CC_FLAGS_LTO   := -flto
+else
 CC_FLAGS_LTO   := -flto=thin -fsplit-lto-unit
+
+# The following clang options added on 2026-02-27 lack distributed
+# ThinLTO support until the 2026-04-24. Disabling for distributed
+# builds until the minimum clang version is updated.
+ifdef CONFIG_LTO_CLANG_THIN
 KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility
-mllvm -always-rename-promoted-locals=false)
-else
-CC_FLAGS_LTO   := -flto
+endif
 endif
 CC_FLAGS_LTO   += -fvisibility=hidden
=====

If you are fine with this, I can send v10 for review.

>
> --
> Cheers,
> Nathan

Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO

[Nathan Chancellor]

On Fri, May 22, 2026 at 08:29:53PM -0700, Rong Xu wrote:
> Thanks Nathan for comments and suggestions. My comments are inlined.
> 
> On Fri, May 22, 2026 at 6:17 PM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > On Fri, May 22, 2026 at 11:58:35AM -0700, Rong Xu wrote:
> > > On Fri, May 22, 2026 at 11:44 AM Yonghong Song <yonghong.song@linux.dev> wrote:
> > > > On 5/22/26 11:14 AM, Rong Xu wrote:
> > > > > On Fri, May 22, 2026 at 10:52 AM Yonghong Song <yonghong.song@linux.dev> wrote:
> > > > >> On 5/22/26 8:32 AM, Rong Xu wrote:
> > > > >>> On Thu, May 21, 2026 at 2:57 PM Yonghong Song <yonghong.song@linux.dev> wrote:
> > > > >>>>
> > > > >>>> On 5/21/26 11:31 AM, Rong Xu wrote:
> > > > >>>>> Yonghong, thanks for the update.
> > > > >>>>>
> > > > >>>>> Regarding this guard: ther is a period of Clang (before this patch and
> > > > >>>>> after your first patch), even though ld.lld having these options
> > > > >>>>> (specifically --lto-whole-program-visibility -mllvm
> > > > >>>>> -always-rename-promoted-locals=false), distributed ThinLTO mode
> > > > >>>>> remains unsupported, correct? What the behvior of using this options
> > > > >>>>> in distributed mode with these compilers? nop or it will lead to
> > > > >>>>> error?
> > > > >>>> The in-process thin-lto support is landed on Feb 27.
> > > > >>>> The distributed thin-lto support is landed on Apr 24.
> > > > >>>>
> > > > >>>> If people are using distributed thin-lto in kernel between Feb 27 and
> > > > >>>> Apr 24, there will be some issues. But people typically use released
> > > > >>>> compiler, so we should be fine.
> > > > >>> This is not the case for us (google). We do use compiler b/w releases,
> > > > >>> and we build our own.
> > > > >>>
> > > > >>> What is the issue if we use the compiler in b/w Feb27 and Apr24?
> > > > >> If you use the custom compiler between Feb27 and Apr24 and your kernel
> > > > >> will do distributed thin-lto, you can remove
> > > > >>      $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> > > > >> from your kernel. Since you have custom compiler, you can
> > > > >> do some customization for your kernel as well.
> > > > > I am referring to this specific patch -- there are cases that use
> > > > > custom compilers built between the February 27 and April 24 LLVM
> > > > > releases.
> > > > > I don't want to see any breakage for distributed ThinLTO in these cases.
> > > > >
> > > > > I would prefer to keep this guard for distributed ThinLTO for the time
> > > > > being and remove it later. What do you think?
> > > >
> > > > For 'remove it later', when this will happen? When llvm23 cuts the rc
> > > > in July or cut the release in September or the end of bug fix say in December?
> > >
> > > I can remove the guard when the minimal clang containis the 4/24 patch.
> >
> > I think we could just change
> >
> >   ifdef CONFIG_LTO_CLANG_THIN
> >   KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> >   endif
> >
> > to
> >
> >   ifneq ($(CONFIG_LTO_CLANG_THIN)$(CONFIG_LTO_CLANG_THIN_DIST),)
> >   KBUILD_LDFLAGS += $(if $(call clang-min-version,230100),--lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false)
> >   endif
> >
> > when LLVM 23.1.0-rc1 is out to avoid that Feb 27 to Apr 24 breakage?
> 
> I don't understand why we need this new "ifneq ..." guard. We have
> already checked CONFIG_LTO_CLANG=y, and CONFIG_LTO_CLANG_FULL != y.
> I think this "ifnef ..." will always be true (so redundant).

Ah, yeah, I missed since I did not look at the full context. That could
just be

  ifneq ($(call clang-min-version,230100),)
  KBUILD_LDFLAGS += --lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false
  endif

then.

> >
> > > > If we carry the guard (for distributed thinlto) in this kernel release,
> > > > that means at some point, we will need to do kernel backport, extra work.
> > >
> > > I don't understand here: this is part of the distributed thinlto patch
> > > that you would need merge anyay.
> > > where is the extra work for backporting?
> > >
> > > > Also, since you are building custom in-development compiler, you can
> > > > disable this flag -always-rename-promoted-locals, problem solved, right?
> > >
> > > I'm not only talking about me. There are other users also use this way.
> > > BTW, even in google, I don't control the compiler that being used.
> >
> > So in general, we assume that folks who are using prerelease compilers
> > (i.e., 23.0.0 in this case) are upgrading them regularly, as we may need
> > to workaround or fix issues that happen in main that cannot be
> > dynamically detected (at least not easily or conveniently). For example,
> > recent main versions of clang have support for -Wattribute-alias, so we
> > need to turn it off via #pragmas like done for GCC, which will break
> > things for clang-23 versions that do not have -Wattribute-alias:
> >
> >   https://git.kernel.org/nathan/c/bc5ffe737f56ee2734597069ed71f48830549483
> >
> > So the argument about breaking compilers in between Feb 27 and Apr 24 is
> > not really relevant in my opinion since they should be short lived in
> > terms of deployment. However, given that things work the way the check
> > is currently written and the LLVM 23 branch is only a couple of months
> > away, I am fine with just sticking with how it is currently written and
> > updating it when things are more guaranteed to work.
> 
> This works for me. I can add a comment here.
> Like the following:
> =====
>  ifdef CONFIG_LTO_CLANG
> -ifdef CONFIG_LTO_CLANG_THIN
> +ifdef CONFIG_LTO_CLANG_FULL
> +CC_FLAGS_LTO   := -flto
> +else
>  CC_FLAGS_LTO   := -flto=thin -fsplit-lto-unit
> +
> +# The following clang options added on 2026-02-27 lack distributed
> +# ThinLTO support until the 2026-04-24. Disabling for distributed
> +# builds until the minimum clang version is updated.

I think the dates are just noise. I think we can keep it short and sweet
with something like:

  # These LLVM options were initially added with only in-process ThinLTO
  # support, so avoid distributed ThinLTO support for now.

Otherwise, seems fine to me. I will set a reminder to revisit this when
LLVM 23 has branched so we can just turn it into a version check.

> +ifdef CONFIG_LTO_CLANG_THIN
>  KBUILD_LDFLAGS += $(call ld-option,--lto-whole-program-visibility
> -mllvm -always-rename-promoted-locals=false)
> -else
> -CC_FLAGS_LTO   := -flto
> +endif
>  endif
>  CC_FLAGS_LTO   += -fvisibility=hidden
> =====
> 
> If you are fine with this, I can send v10 for review.
> 
> >
> > --
> > Cheers,
> > Nathan

-- 
Cheers,
Nathan