From owner-cvs-all@FreeBSD.ORG Tue Jul 22 08:24:57 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 11FC237B401; Tue, 22 Jul 2003 08:24:57 -0700 (PDT) Received: from godel.mtl.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A6FC43FB1; Tue, 22 Jul 2003 08:24:56 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: from godel.mtl.distributel.net (localhost [127.0.0.1]) h6MBT2EH059117; Tue, 22 Jul 2003 11:29:02 GMT (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by godel.mtl.distributel.net (8.12.9/8.12.9/Submit) id h6MBT16j059116; Tue, 22 Jul 2003 11:29:01 GMT X-Authentication-Warning: godel.mtl.distributel.net: bmilekic set sender to bmilekic@technokratis.com using -f Date: Tue, 22 Jul 2003 11:29:01 +0000 From: Bosko Milekic To: Bruce Evans Message-ID: <20030722112901.GA59012@technokratis.com> References: <200307221024.h6MAOggG066724@repoman.freebsd.org> <20030722093443.GD58118@technokratis.com> <20030723003823.R8380@gamplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030723003823.R8380@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 15:24:57 -0000 On Wed, Jul 23, 2003 at 12:54:22AM +1000, Bruce Evans wrote: > Inlining was broken in gcc-3.1 (2002/05/09). subr_mbuf.c worked as intended > for almost a year until then. subr_mbuf.c now doesn't even attempt to work > like its comments say it is intended to: > > % /****************************************************************************** > % * Internal routines. > % * > % * Because mb_alloc() and mb_free() are inlines (to keep the common > % * cases down to a maximum of one function call), below are a few > % * routines used only internally for the sole purpose of making certain > % * functions smaller. > % */ > > But mb_alloc() and mb_free() aren't inlines... > > > I guess GCC's warnings just got fixed recently. > > I suspect the warning got broken in gcc-3.1 too. It seemed to work > perfectly when I turned it back on in 1997 (bsd.kern.mk 1.6). However, > it can't have been completely broken for gcc-3.1, since I needed to > turn it off for the high-resolution profiling case. > > Bruce Yeah, hmmmm. :-( Is there a way to force GCC to inline them, despite what it thinks? As I said on some other list, in retrospect, I would re-evaluate the way this is done but currently have diverted my attention to a somewhat different approach. 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. P.S.: I've re-added the src-committers, cvs-src, and cvs-all lists to the To header as I'm curious if anyone else knows the answer as well. I hope you don't mind. Regards, -- Bosko Milekic * bmilekic@technokratis.com * bmilekic@FreeBSD.org TECHNOkRATIS Consulting Services * http://www.technokratis.com/