Date: Sun, 12 Apr 2015 12:14:22 +0200
From: Ingo Molnar <mingo@kernel.org>
To: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Denys Vlasenko <dvlasenk@redhat.com>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Jason Low <jason.low2@hp.com>, Peter Zijlstra <peterz@infradead.org>,
        Davidlohr Bueso <dave@stgolabs.net>,
        Tim Chen <tim.c.chen@linux.intel.com>,
        Aswin Chandramouleeswaran <aswin@hp.com>,
        LKML <linux-kernel@vger.kernel.org>, Borislav Petkov <bp@alien8.de>,
        Andy Lutomirski <luto@amacapital.net>, Brian Gerst <brgerst@gmail.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>
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
Content-Length: 1449
Lines: 38


* Markus Trippelsdorf <markus@trippelsdorf.de> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/