Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO
From: Yonghong Song
Date: Fri May 22 2026 - 14:44:40 EST
On 5/22/26 11:14 AM, Rong Xu wrote:
On Fri, May 22, 2026 at 10:52 AM Yonghong Song <yonghong.song@xxxxxxxxx> wrote:
I am referring to this specific patch -- there are cases that use
On 5/22/26 8:32 AM, Rong Xu wrote:
On Thu, May 21, 2026 at 2:57 PM Yonghong Song <yonghong.song@xxxxxxxxx> wrote:If you use the custom compiler between Feb27 and Apr24 and your kernel
This is not the case for us (google). We do use compiler b/w releases,
On 5/21/26 11:31 AM, Rong Xu wrote:
Yonghong, thanks for the update.The in-process thin-lto support is landed on Feb 27.
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 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.
and we build our own.
What is the issue if we use the compiler in b/w Feb27 and Apr24?
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.
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 meThere is no need to keep compiler version guard.
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?
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@xxxxxxxxx> wrote:
On 3/31/26 9:27 AM, Nathan Chancellor wrote:
Hi Rong,The above patch has a guard CONFIG_LTO_CLANG_THIN, which can be removed.
On Tue, Mar 31, 2026 at 03:48:27PM +0000, xur@xxxxxxxxxx wrote:
diff --git a/Makefile b/MakefileThis should be an 'ifdef', not an 'if'. You copied Yonghong's mistake:
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
https://lore.kernel.org/abgRRX3PH9IaExi8@xxxxxxxxxxxxx/
https://lore.kernel.org/6db3a2f6-d61c-42f1-9b9d-0aca021cc2d7@xxxxxxxxx/
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
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.
endifWith that addressed above, the series survives my basic LLVM 22.1.2
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' \
build test with my distribution configuration. I'll provide formal tags
on a properly tested and fixed revision.
Cheers,
Nathan