Re: [GIT] kbuild/lto changes for 3.15-rc1

[Ingo Molnar <mingo@kernel.org>]

* Markus Trippelsdorf <markus@trippelsdorf.de> wrote:

> On 2014.04.15 at 20:19 +0200, Sam Ravnborg wrote:
> > On Tue, Apr 15, 2014 at 01:36:02PM +0200, Markus Trippelsdorf wrote:
> > > On 2014.04.15 at 13:19 +0200, Sam Ravnborg wrote:
> > > > > 
> > > > > And while the code size reduction is less for MIPS than what others have
> > > > > reported for their platforms (I'm still investigating) is still is enough
> > > > > that embedded developers would commit murder for.
> > > > 
> > > > I have experimented a little with a patch that links all of vmlinux in one step.
> > > > I compared the text size of vmlinux without and with -ffunction-sections.
> > > > 
> > > > With a defconfig build on x86 (32 bit) I got following results:
> > > > 
> > > >                         size     difference
> > > > singlelink          10266506
> > > > function-sections    9487369         779137  7,5%
> > > > 
> > > > So this is a reduction of ~800 kb by enabling -ffunction-sections which
> > > > allows the linker to throw away unused sections.
> > > > 
> > > > I have not boot tested the kernel so chances are that too much was thrown out by the linker.
> > > > But this is an option that has much smaller cost to use than lto.
> > > > And seems to benefit nicely in size.
> > > > 
> > > > I have not tried this wihtout my singlelink patch - but I assume similar results.
> > > 
> > > No, it wouldn't work, because you cannot mix -r and --gc-sections (or
> > > gold's --icf (identical code folding)).
> 
> BTW using --gc-sections during vmlinux link time will not work, because
> it will "garbage collect" the whole kernel away.
> 
> > With make allnoconfig I see a 5% decrease in text size by applying -ffunction-sections.
> > This is with latest mainline and no other than the following applied:
> > 
> > diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> > index 602f57e..51bac0a 100644
> > --- a/arch/x86/Makefile
> > +++ b/arch/x86/Makefile
> > @@ -171,6 +171,8 @@ KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
> >  KBUILD_CFLAGS += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
> >  KBUILD_CFLAGS += $(call cc-option,-mno-avx,)
> >  
> > +KBUILD_CFLAGS += -ffunction-sections
> > +
> >  KBUILD_CFLAGS += $(mflags-y)
> >  KBUILD_AFLAGS += $(mflags-y)
> >  
> > 
> > What can then explain this size difference?

I haven't looked at this for some time, but won't the linker eliminate 
unused input sections by default, unless told not to do that? (You 
have to add --no-gc-sections explicitly to turn this off.)

That would mean that with per function sections, unused global 
functions are eliminated. 'Unused' here means that the section only 
contains symbols that are not referenced anywhere else. With 
-ffunction-sections we'll have a lot of small per function sections, 
with a single symbol in them (the function) most of the time, IIRC.

> That is a good question. Because one would expect that adding 
> -ffunction-sections should increase the size (and it does with my 
> config).

--gc-sections appears to be platform dependent, so I suspect it 
depends on the platform.

But if -ffunction-sections can be made to work and has fewer downsides 
than the upsides then that approach should be tried first, and then 
LTO should be compared to that baseline.

Thanks,

	Ingo