Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750772AbVL3U7P (ORCPT ); Fri, 30 Dec 2005 15:59:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750725AbVL3U7P (ORCPT ); Fri, 30 Dec 2005 15:59:15 -0500 Received: from mailout.stusta.mhn.de ([141.84.69.5]:6409 "HELO mailout.stusta.mhn.de") by vger.kernel.org with SMTP id S1750770AbVL3U7M (ORCPT ); Fri, 30 Dec 2005 15:59:12 -0500 Date: Fri, 30 Dec 2005 21:59:11 +0100 From: Adrian Bunk To: Alan Cox Cc: Andrew Morton , Ingo Molnar , torvalds@osdl.org, arjan@infradead.org, linux-kernel@vger.kernel.org, mpm@selenic.com Subject: Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers Message-ID: <20051230205911.GZ3811@stusta.de> References: <20051228114637.GA3003@elte.hu> <1135798495.2935.29.camel@laptopd505.fenrus.org> <20051228212313.GA4388@elte.hu> <20051228214845.GA7859@elte.hu> <20051228201150.b6cfca14.akpm@osdl.org> <1135956480.28365.16.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1135956480.28365.16.camel@localhost.localdomain> User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1721 Lines: 43 On Fri, Dec 30, 2005 at 03:28:00PM +0000, Alan Cox wrote: > On Mer, 2005-12-28 at 20:11 -0800, Andrew Morton wrote: > > If no-forced-inlining makes the kernel smaller then we probably have (yet > > more) incorrect inlining. We should hunt those down and fix them. We did > > quite a lot of this in 2.5.x/2.6.early. Didn't someone have a script which > > would identify which functions are a candidate for uninlining? > > There is a tool that does this quite well. Its called "gcc" ;) > > More seriously we need to seperate "things Andrew thinks are good inline > candidates" and "things that *must* be inlined". That allows 'build for > size' to do the equivalent of "-Dplease_inline" and the other build to > do "-Dplease_inline=inline". Gcc's inliner isn't aware of things cross > module so isn't going to make all the decisions right, but will make the > tedious local decisions. >... I'm not getting the point: Shouldn't "static" versus not "static" already give gcc everything it needs for making the decision? If stuff is cross-module (more exactly: cross-objects) it's not static and I doubt there are many (if any) cases of non-static code we want inline'd when used inside the file it's in. > Alan cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/