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

[Nathan Chancellor]

On Thu, May 28, 2026 at 12:04:59PM -0700, Rong Xu wrote:
> On Wed, May 27, 2026 at 5:54 PM Nathan Chancellor <nathan@xxxxxxxxxx> wrote:
> >
> > On Tue, 26 May 2026 10:29:26 -0700, xur@xxxxxxxxxx <xur@xxxxxxxxxx> wrote:
> > > 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
> >
> > Sashiko notes that we might want modkern_cflags here as well, which
> > seems like it could really matter for LoongArch?
> >
> >   https://sashiko.dev/#/patchset/25040?part=3
> >
> This is a valid point, as users have the ability to add new flags via
> KBUILD_KERNL_FLAGS and they are likely needed to pass the backend. I
> will update saved_c_flags to include modkern_cflags.
> 
> > The other comments might be relevant too but I did not look too closely
> > as I am wrapping up my day but I wanted to bring this to your attention
> > sooner rather than later.
> 
> The second comment concerns using a shell script to get _c_flags: I
> opted for this method instead of $(saved_c_flags_$(<) to avoid loading
> $(<).cmd in the Makefile. Note that I only load $(@).cmd at the end of
> the file. However, if we would rather use the latter approach, I can
> make that change, though it will require loading $(<).cmd file.

Yeah, I think it is fine to leave it this way for now. If someone can
prove it matters for a significant amount of performance, we can
revisit.

> The third comment concerns file name matching: That is a fair point; I
> should have implemented a more precise matching criteria. I will
> address and fix this.
> 
> I disagree with some of the comments regarding compile times. We have
> tested this build mode extensively and observed no compile-time
> regressions compared to the existing in-process ThinLTO build.

Yeah, I tend to agree that the performance concerns are overblown.

> I will send the updated patch shortly, after I tested the changes.

Thanks!

-- 
Cheers,
Nathan