Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

[Ingo Molnar <mingo@elte.hu>]

* Linus Torvalds <torvalds@osdl.org> wrote:

> > i think there's quite an attitude here - we are at the mercy of "gcc 
> > brainfarts" anyway, and users are at the mercy of "kernel brainfarts" 
> > just as much.
> 
> There's a huge difference here. The gcc people very much have a "Oh, 
> we changed old documented behaviour - live with it" attitude, together 
> with "That was a gcc extension, not part of the C language, so when we 
> change how gcc behaves, it's _your_ problem" approach.
> 
> At least they used to.

yeah, i think that was definitely the case historically.

> Maybe the right thing to do is to just heed that warning, and remove 
> such functions from header files and make them no-inline? That way we 
> get the size fixes _regardless_ of any compiler options.

i think the eye-opener (for me at least) was that there's really a
massive 5%+ size difference here, from 2 simple patches. And meanwhile
Matt is doing truly hard size-reduction work and is mailing patches to
lkml that remove 200-300 bytes of .text, which is 0.01% of code, apiece.

Debloating is like scalability, a piece-by-piece process where we'll
only see the full effects after doing 100 independent steps, but still
we must not ignore the big effects either, nor must we get ourselves
into losing maintainance battles.

The current inline model seems to be a lost battle, the 'size noise'
caused by spurious inlines (which count in the thousands) is _far_
outpowering most of the size reduction efforts. And i think it can be
argued that at least in the -Os case gcc has a very clear directive wrt.
what to do - and much less room to mess up. Independently of how much we
trust it.

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/