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@xxxxxxxxx> wrote:
>
>
>
> 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:
> >>
> >>
> >> 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:
> >>>>
> >>>> 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@xxxxxxxxx> wrote:
> >>>>>> On 3/31/26 9:27 AM, Nathan Chancellor wrote:
> >>>>>>> Hi Rong,
> >>>>>>>
> >>>>>>> On Tue, Mar 31, 2026 at 03:48:27PM +0000, xur@xxxxxxxxxx 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@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
> >>>>>> 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
>