From owner-cvs-all@FreeBSD.ORG Tue Jul 22 10:27:16 2003 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 994AA37B401; Tue, 22 Jul 2003 10:27:16 -0700 (PDT) Received: from godel.mtl.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9C0743F85; Tue, 22 Jul 2003 10:27:15 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: from godel.mtl.distributel.net (localhost [127.0.0.1]) h6MDVMEH059953; Tue, 22 Jul 2003 13:31:22 GMT (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by godel.mtl.distributel.net (8.12.9/8.12.9/Submit) id h6MDVLrW059952; Tue, 22 Jul 2003 13:31:21 GMT X-Authentication-Warning: godel.mtl.distributel.net: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 22 Jul 2003 13:31:21 +0000 From: Bosko Milekic To: Bruce Evans Message-ID: <20030722133121.GA59912@technokratis.com> References: <200307221024.h6MAOggG066724@repoman.freebsd.org> <20030722093443.GD58118@technokratis.com> <20030723003823.R8380@gamplex.bde.org> <20030722112901.GA59012@technokratis.com> <20030723022239.F8681@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030723022239.F8681@gamplex.bde.org> User-Agent: Mutt/1.4.1i cc: cvs-src@FreeBSD.org cc: phk@phk.freebsd.dk cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern init_main.c kern_malloc.c md5c.c subr_autoconf.c subr_mbuf.c subr_prf.c tty_subr.c vfs_cluster.c vfs_subr.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 17:27:16 -0000 On Wed, Jul 23, 2003 at 02:35:31AM +1000, Bruce Evans wrote: [... very good explanation ommitted... ] > > What concerns me about GCC's idea of what is "inlinable" code and what > > is not is that in some scenarios (admittedly this may not be the case > > for mb_alloc), we will have an inlined version of some function for an > > application such as the following: > > > > inline-function-A() { > > blah blah; > > } > > > > /* Exported API */ > > real-out-of-line-function1() { > > inline-function-A(); > > if (one_more_thing) > > try_this(); > > } > > > > /* Some other Exported API */ > > real-out-of-line-function2() { > > inline-function-A(); > > } > > > > In such a scenario, the inline-function-A(), only inlined in two > > places, reduces code duplication. Even if it's slightly bigger than > > what GCC thinks "is OK," I could still see a legitimate reason for > > inlining it. > > I think gcc's inlining heuristics are tuned towards automatic inlining, > and it should try harder for explicit inline keywords (for C, maybe > not for C++). Maybe we should set the inlining limits to infinity for > the kernel since we know what we are doing with the inline keywords > (just like for register keywords ;-) and we don't use automatic > inlining. > > Bruce I would tend to lean in this direction as well. Just blindly turning all our inlines that GCC now builds as functions into functions does not seem like a good solution. I see these commits flying by, notably the recent one in fxp, and I'm wondering if perhaps one or two of those functions that were changed could have stayed inlines, were it not for the nested inlining, as you point out above. At the same time, at least this warning exposed that we should carefully re-evaluate what we inline and when. -- Bosko Milekic * bmilekic@technokratis.com * bmilekic@FreeBSD.org TECHNOkRATIS Consulting Services * http://www.technokratis.com/