Re: kernel: Current status of CONFIG_CC_OPTIMIZE_FOR_SIZE=y (was: Re: [PATCH -tip] x86/locking/atomic: Use asm_inline for atomic locking insns)

["Arnd Bergmann" <arnd@arndb.de>]

On Thu, Mar 6, 2025, at 10:43, Ingo Molnar wrote:
> * Uros Bizjak <ubizjak@gmail.com> wrote:
>> On Wed, Mar 5, 2025 at 10:26 PM Peter Zijlstra <peterz@infradead.org> wrote:
> So the best way to drive -Os forward is not to insist that it's good 
> (it might still be crap), and not to insist that it's crap (it might 
> have become better), but to dig out old problems and to look at what 
> kind of code current compilers generate in the kernel with -Os.
>
> There's been a few pathological GCC optimizations in the past, but also 
> other problems, such as this one 9 years ago that hid useful warnings:
>
>   =================>
>   877417e6ffb9 Kbuild: change CC_OPTIMIZE_FOR_SIZE definition
>   =================>
>
>   From: Arnd Bergmann <arnd@arndb.de>
>   Date: Mon, 25 Apr 2016 17:35:27 +0200
>   Subject: [PATCH] Kbuild: change CC_OPTIMIZE_FOR_SIZE definition
>
>     CC_OPTIMIZE_FOR_SIZE disables the often useful -Wmaybe-unused warning,
>     because that causes a ridiculous amount of false positives when combined
>     with -Os. 

I think that should have said '-Wmaybe-uninitialized', which is a thing
of the past, since (IIRC) gcc-9 changed the default inlining rules and
Linus turned it off globally after the false positives started happening
with -O2 as well.

This is rather annoying of course, since we miss a lot of warnings
for real bugs, but at least clang's -Wsometimes-uninitialized and
smatch still catch the important ones in the CI systems, but we keep
seeing new ones in linux-next and have to patch them.

> But yes, I'd cautiously agree that reduced kernel size with a -Os build 
> is a stochastic proxy metric for better code and better performance - 
> but it comes with caveats and needs to be backed by other data or 
> robust first principles arguments too.

My impression is that for the most part, the -Os and -O2 options do
exactly what they promise, picking either a smaller or faster object
code. Clearly there is no single ideal choice because if some
optimization step is a win for both performance and size it would
be turned on for both.

The crazy options (-Oz and -O3) on the other hand are intentionally
not offered by Kconfig.

      Arnd