Re: [PATCH] compiler_types: Introduce inline_for_performance

[Nick Desaulniers <ndesaulniers@google.com>]

On Mon, Jan 19, 2026 at 11:33:29AM +0100, Eric Dumazet wrote:
> > Many __always_inline came because of clang's reluctance to inline
> > small things, even if the resulting code size is bigger and slower.
> >
> > It is a bit unclear, this seems to happen when callers are 'big
> > enough'.

Haha, yes, and I've read LLVM's inline cost model before and "a bit
unclear" is how I feel about it.  At this point, some of your Google
compatriots have even resorted to AI for inlining.

https://arxiv.org/pdf/2101.04808

> > noinstr (callers) functions are also a problem.
> >
> > Let's take the list_add() call from dev_gro_receive() : clang does not
> > inline it, for some reason.
> >
> > After adding __always_inline to list_add() and __list_add() we have
> > smaller and more efficient code,
> > for real workloads, not only benchmarks.

Yeah, ChromeOS is hitting this now, too.  They're deploying AutoFDO
where you collect traces with LBR (x86) / ETM,TRBE,BRBE,SPE (ARM) then
feed that back into the compiler.  Then they're getting modpost warnings
from section mismatches when constant propagation sinks addresses of
initdata globals into specialized copies of list_add that are then not
inlined (so not placed in .init).

https://github.com/ClangBuiltLinux/linux/issues/2173

I think list_add, __list_add, and probably __list_del_entry_valid should
be always_inline, possibly except for the different definitions when
CONFIG_LIST_HARDENED is set.