Date: Tue, 22 Jul 2003 13:31:21 +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: <20030722133121.GA59912@technokratis.com> In-Reply-To: <20030723022239.F8681@gamplex.bde.org> References: <200307221024.h6MAOggG066724@repoman.freebsd.org> <20030722093443.GD58118@technokratis.com> <20030723003823.R8380@gamplex.bde.org> <20030722112901.GA59012@technokratis.com> <20030723022239.F8681@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030722133121.GA59912>