Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753924AbZAIQrQ (ORCPT ); Fri, 9 Jan 2009 11:47:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752670AbZAIQq6 (ORCPT ); Fri, 9 Jan 2009 11:46:58 -0500 Received: from bombadil.infradead.org ([18.85.46.34]:44828 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752409AbZAIQq4 (ORCPT ); Fri, 9 Jan 2009 11:46:56 -0500 Date: Fri, 9 Jan 2009 08:46:20 -0800 From: Dirk Hohndel To: "H. Peter Anvin" Cc: Ingo Molnar , jim owens , Linus Torvalds , Chris Mason , Peter Zijlstra , Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Matthew Wilcox , Andi Kleen , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich Subject: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact Message-ID: <20090109084620.3c711aad@infradead.org> In-Reply-To: <49677CB1.3030701@zytor.com> References: <20090108141808.GC11629@elte.hu> <1231426014.11687.456.camel@twins> <1231434515.14304.27.camel@think.oraclecorp.com> <20090108183306.GA22916@elte.hu> <496648C7.5050700@zytor.com> <20090109130057.GA31845@elte.hu> <49675920.4050205@hp.com> <20090109153508.GA4671@elte.hu> <49677CB1.3030701@zytor.com> X-Mailer: Claws Mail 3.6.1 (GTK+ 2.14.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1138 Lines: 31 On Fri, 09 Jan 2009 08:34:57 -0800 "H. Peter Anvin" wrote: > > As far as naming is concerned, gcc effectively supports four levels, > which *currently* map onto macros as follows: > > __always_inline Inline unconditionally > inline Inlining hint > Standard heuristics > noinline Uninline unconditionally > > A lot of noise is being made about the naming of the levels (and I > personally believe we should have a different annotation for "inline > unconditionally for correctness" and "inline unconditionally for > performance", as a documentation issue), but those are the four we > get. Does gcc actually follow the "promise"? If that's the case (and if it's considered a bug when it doesn't), then we can get what Linus wants by annotating EVERY function with either __always_inline or noinline. /D -- Dirk Hohndel Intel Open Source Technology Center -- 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/