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
2025-03-06T10:38:25Z

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