diff mbox

[GIT] kbuild/lto changes for 3.15-rc1

Message ID 20140415181945.GA22608@ravnborg.org (mailing list archive)
State New, archived
Headers show

Commit Message

Sam Ravnborg April 15, 2014, 6:19 p.m. UTC
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)).
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:


What can then explain this size difference?

	Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Markus Trippelsdorf April 15, 2014, 6:29 p.m. UTC | #1
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?

That is a good question. Because one would expect that adding
-ffunction-sections should increase the size (and it does with my
config).
Ingo Molnar April 16, 2014, 6:49 a.m. UTC | #2
* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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)