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.
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.
--
Josh
