From: Yonghong Song <yonghong.song@linux.dev>
To: Rong Xu <xur@google.com>
Cc: Nathan Chancellor <nathan@kernel.org>,
Masahiro Yamada <masahiroy@kernel.org>,
Nicolas Schier <nicolas.schier@linux.dev>,
Nick Desaulniers <nick.desaulniers+lkml@gmail.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
Miguel Ojeda <ojeda@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Alice Ryhl <aliceryhl@google.com>,
Sami Tolvanen <samitolvanen@google.com>,
"Mike Rapoport (Microsoft)" <rppt@kernel.org>,
Rafael Aquini <aquini@redhat.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Stafford Horne <shorne@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Piotr Gorski <piotrgorski@cachyos.org>,
Venkat Rao Bagalkote <venkat88@linux.ibm.com>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Teresa Johnson <tejohnson@google.com>,
linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org,
llvm@lists.linux.dev
Subject: Re: [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO
Date: Thu, 21 May 2026 14:56:53 -0700 [thread overview]
Message-ID: <69e60bc9-cfe6-4b8d-b61b-5840f7d2518a@linux.dev> (raw)
In-Reply-To: <CAF1bQ=R6=0G9O-eNFsHiCLMpkph7=hSu4Rn_HjFD4PvTFnAnDQ@mail.gmail.com>
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
next prev parent reply other threads:[~2026-05-21 21:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-31 15:48 [PATCH v9 0/3] kbuild: distributed build support for Clang ThinLTO xur
2026-03-31 15:48 ` [PATCH v9 1/3] kbuild: move vmlinux.a build rule to scripts/Makefile.vmlinux_a xur
2026-03-31 15:48 ` [PATCH v9 2/3] kbuild: change --thin back to 'T' in $(AR) xur
2026-03-31 15:48 ` [PATCH v9 3/3] kbuild: distributed build support for Clang ThinLTO xur
2026-03-31 16:27 ` Nathan Chancellor
2026-05-21 17:57 ` Yonghong Song
2026-05-21 18:31 ` Rong Xu
2026-05-21 21:56 ` Yonghong Song [this message]
2026-05-22 15:32 ` Rong Xu
2026-05-22 17:51 ` Yonghong Song
2026-05-22 18:14 ` Rong Xu
2026-05-22 18:44 ` Yonghong Song
2026-05-22 18:58 ` Rong Xu
2026-05-23 1:17 ` Nathan Chancellor
2026-05-23 3:29 ` Rong Xu
2026-05-23 3:55 ` Nathan Chancellor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=69e60bc9-cfe6-4b8d-b61b-5840f7d2518a@linux.dev \
--to=yonghong.song@linux.dev \
--cc=aliceryhl@google.com \
--cc=aquini@redhat.com \
--cc=christophe.leroy@csgroup.eu \
--cc=justinstitt@google.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=masahiroy@kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=morbo@google.com \
--cc=mpe@ellerman.id.au \
--cc=nathan@kernel.org \
--cc=nick.desaulniers+lkml@gmail.com \
--cc=nicolas.schier@linux.dev \
--cc=ojeda@kernel.org \
--cc=piotrgorski@cachyos.org \
--cc=rppt@kernel.org \
--cc=samitolvanen@google.com \
--cc=shorne@gmail.com \
--cc=tejohnson@google.com \
--cc=tglx@linutronix.de \
--cc=venkat88@linux.ibm.com \
--cc=xur@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.