Re: [PATCH kbuild] kbuild: Allow to reduce the number of suffixes for clang thin-lto build

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

On 3/6/26 12:57 PM, Josh Poimboeuf wrote:
> On Fri, Mar 06, 2026 at 12:55:02PM -0800, Josh Poimboeuf wrote:
>> On Fri, Mar 06, 2026 at 11:40:21AM -0800, Yonghong Song wrote:
>>>> Thanks!  Would there be any downsides to enabling this feature
>>>> unconditionally in the kernel when the compiler supports it?
>>> The only downside is for the following case:
>>>
>>> C   file: static function foo()
>>> Asm file: global function foo()
>>>
>>> The thin-lto will collect all C files and with the above llvm patch,
>>> the static function foo() may be promoted to global function foo()
>>> if there is no other pre-existing global function foo() in all C files.
>>>
>>> In such cases, there will be a conflict since
>>> there are two global function foo() (one from C file, another from Asm file).
>>> In such cases, the build will fail.
>>>
>>> How do you think we could hit such issues in linux kernel?
>>> Maybe should have default no for the new config?
>>>
>>> I think the chance should be very low. The following is a grab for x86
>>> for global symbols in asm code:
>>>
>>> [~/work/others/linux/arch/x86 (master)]$ egrep -r globl
>> There are actually quite a bit more than that, see SYM_CODE_START:
>>
>>    $ git grep 'SYM_CODE_START(' |wc -l
>>    169
>>
>> But still, I agree the chance of a conflict would be very low.  And
>> global assembly functions tend to be rather uniquely named.
>>
>>> Maybe we could collect all global symbols in asm codes before lld,
>>> and then we add an option in lld to feed those global symbols (with a file?),
>>> then we can be sure there won't be any conflict?
>> That wouldn't be worth the effort in my opinion.
>>
>> I think we should just unconditionally enable
>> -always-rename-promoted-locals=false when it's available.  While that
>> will implicitly enforce that global asm functions be uniquely named
>> across the tree, I don't see that as a problem.  In the rare case of a
>> conflict, we can just rename the function.

So you mean we do not need a new config. Should just check clang and
clang versionn like below?

diff --git a/Makefile b/Makefile
index e944c6e71e81..9bd3990024c5 100644
--- a/Makefile
+++ b/Makefile
@@ -1034,6 +1034,11 @@ endif
  ifdef CONFIG_LTO_CLANG
  ifdef CONFIG_LTO_CLANG_THIN
  CC_FLAGS_LTO   := -flto=thin -fsplit-lto-unit
+ifdef CONFIG_CC_IS_CLANG
+ifeq ($(shell test $(CONFIG_CLANG_VERSION) -ge 230000; echo $$?),0)
+KBUILD_LDFLAGS += --lto-whole-program-visibility -mllvm -always-rename-promoted-locals=false
+endif
+endif
  else
  CC_FLAGS_LTO   := -flto
  endif

I think this should work. In rare case, renaming the function should
solve the problem.

> BTW, reading this again I realize that this would affect not only global
> asm *functions*, but also global asm *data*.  But asm global data is
> quite rare and also tends to be uniquely named, so my conclusion is the
> same.
>
With thin-lto, the cross-file data inlining is a side effect of
cross-file function inlining. So the number of cross-file data inlining
is small. Compared to 1212 number of functions with suffix .llvm.<hash>,
the number of data with suffix only 9:

ffffffff84e8ad09 d __func__.net_ratelimit.llvm.12310750674033017485
ffffffff84f1d569 d .str.llvm.11541892489833206993
ffffffff87f42d40 b __cfs_bandwidth_used.llvm.9245315756205243639
ffffffff87f457c0 b __sched_clock_stable.llvm.13183765431478218167
ffffffff881968d0 b lock_chains_in_use.llvm.17116087415131265585
ffffffff88bba180 b timekeeper_data.llvm.4127123038948722377
ffffffff88bd0eb0 b slab_debugfs_root.llvm.537776758349482510
ffffffff88c0b300 b __acpi_os_prepare_sleep.llvm.3969442148434754585
ffffffff88c63b00 b handshake_rhashtbl.llvm.12810142853876704317

With newly added KBUILD_LDFLAGS flags, none of them have suffixes.
Again, the conflict for data variable should be rare too.

I will repost the patch with Makefile change once llvm23 release
is cut.

Thanks!