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

[Bosko Milekic]

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 at technokratis.com  *  bmilekic at FreeBSD.org
TECHNOkRATIS Consulting Services  *  http://www.technokratis.com/