Date: Tue, 22 Jul 2003 11:29:01 +0000 From: Bosko Milekic <bmilekic@technokratis.com> To: Bruce Evans <bde@zeta.org.au> 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 Message-ID: <20030722112901.GA59012@technokratis.com> In-Reply-To: <20030723003823.R8380@gamplex.bde.org> References: <200307221024.h6MAOggG066724@repoman.freebsd.org> <20030722093443.GD58118@technokratis.com> <20030723003823.R8380@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030722112901.GA59012>