From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751460AbbDLKO3 (ORCPT ); Sun, 12 Apr 2015 06:14:29 -0400 Received: from mail-wg0-f42.google.com ([74.125.82.42]:35375 "EHLO mail-wg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751150AbbDLKO1 (ORCPT ); Sun, 12 Apr 2015 06:14:27 -0400 Date: Sun, 12 Apr 2015 12:14:22 +0200 From: Ingo Molnar To: Markus Trippelsdorf Cc: "H. Peter Anvin" , Denys Vlasenko , "Paul E. McKenney" , Linus Torvalds , Jason Low , Peter Zijlstra , Davidlohr Bueso , Tim Chen , Aswin Chandramouleeswaran , LKML , Borislav Petkov , Andy Lutomirski , Brian Gerst , Thomas Gleixner , Peter Zijlstra Subject: Re: [PATCH] x86: Align jump targets to 1 byte boundaries Message-ID: <20150412101422.GA2862@gmail.com> References: <20150409183926.GM6464@linux.vnet.ibm.com> <20150410090051.GA28549@gmail.com> <20150410091252.GA27630@gmail.com> <20150410092152.GA21332@gmail.com> <20150410111427.GA30477@gmail.com> <20150410112748.GB30477@gmail.com> <20150410120846.GA17101@gmail.com> <5527C700.3030405@redhat.com> <5527CD92.1080901@zytor.com> <20150411144135.GB31416@x4> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150411144135.GB31416@x4> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Markus Trippelsdorf wrote: > On 2015.04.10 at 06:18 -0700, H. Peter Anvin wrote: > > On 04/10/2015 05:50 AM, Denys Vlasenko wrote: > > > > > > However, I'm an -Os guy. Expect -O2 people to disagree :) > > > > > > > The problem with -Os is that the compiler will make *any* tradeoffs to > > save a byte. It is really designed to squeeze as much code into a > > fixed-size chunk, e.g. a ROM, as possible. > > > > We have asked for an -Okernel mode from the gcc folks forever. It > > basically would mean "-Os except when really dumb." > > If you want the best of both worlds perhaps you should reconsider Andy's > LTO patch? With -flto gcc automatically optimizes all functions that it > considers cold for size. So you could expect some code size savings even > with -O2 (or -O3). In my (past) experience the main win from -flto is not due to better hot/cold decisions, but simply due to more aggressive dead code elimination. -flto has less of an effect on code that is actually being executed. Which isn't to be sneered at, but it's far less of a direct effect as branch probabilities are, which cut to the core of most hotpaths in the kernel. Thanks, Ingo