* Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
