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 bmilekic at technokratis.com
Tue Jul 22 08:24:57 PDT 2003


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


More information about the cvs-src mailing list