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

[Yonghong Song <yonghong.song@linux.dev>]

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