lkml.org 
[lkml]   [2015]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH] x86: Align jump targets to 1 byte boundaries

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

> On 2015.04.13 at 11:31 -0700, Linus Torvalds wrote:
> > On Mon, Apr 13, 2015 at 10:26 AM, Markus Trippelsdorf
> > <markus@trippelsdorf.de> wrote:
> > >
> > > I must have made a measurement mistake above, because the actual code
> > > size savings are roughly 5%:
> >
> > Can you check against the -fno-guess-branch-probability output?
>
> text data bss dec filename
> 8746230 970072 802816 10519118 ./vmlinux gcc-5 (lto)
> 9202488 978512 811008 10992008 ./vmlinux gcc-5
> 8036915 970296 802816 9810027 ./vmlinux gcc-5 (lto -fno-guess-branch-probability)
> 8593615 978512 811008 10383135 ./vmlinux gcc-5 (-fno-guess-branch-probability)

Just to make sure, could you please also apply the 3 alignment patches
attached below? There's a lot of noise from extra alignment.

Having said that, LTO should have three main effects:

1) better cross-unit inlining decisions

2) better register allocation and clobbering knowledge (if a small
function is known not to clobber caller-saved registers, then the
saving can be skipped)

3) better dead code elimination

1)-2) is probably worth the price, 3) in isolation isn't. So we'd have
to estimate which one is how significant, to judge the value of LTO -
but I haven't seen any effort so far to disambiguate it.

_Possibly_ if you build kernel/built-in.o only, and compared its
sizes, that would help a bit, because the core kernel has very little
dead code, giving a fairer estimation of 'true' optimizations.

Thanks,

Ingo

======

arch/x86/Makefile | 9 +++++++++
1 file changed, 9 insertions(+)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5ba2d9ce82dc..10989a73b986 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -77,6 +77,15 @@ else
KBUILD_AFLAGS += -m64
KBUILD_CFLAGS += -m64

+ # Pack jump targets tightly, don't align them to the default 16 bytes:
+ KBUILD_CFLAGS += -falign-jumps=1
+
+ # Pack functions tightly as well:
+ KBUILD_CFLAGS += -falign-functions=1
+
+ # Pack loops tightly as well:
+ KBUILD_CFLAGS += -falign-loops=1
+
# Don't autogenerate traditional x87 instructions
KBUILD_CFLAGS += $(call cc-option,-mno-80387)
KBUILD_CFLAGS += $(call cc-option,-mno-fp-ret-in-387)

\
 
 \ /
  Last update: 2015-04-14 08:01    [W:0.135 / U:1.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site