From owner-cvs-all@FreeBSD.ORG Tue Jul 22 14:23:30 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 3E21737B401; Tue, 22 Jul 2003 14:23:30 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AE7243FBF; Tue, 22 Jul 2003 14:23:29 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id EF8DB2A8B2; Tue, 22 Jul 2003 14:23:28 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Marcel Moolenaar In-Reply-To: <20030722201918.GA1052@athlon.pn.xcllnt.net> Date: Tue, 22 Jul 2003 14:23:28 -0700 From: Peter Wemm Message-Id: <20030722212328.EF8DB2A8B2@canning.wemm.org> cc: "Alan L. Cox" cc: phk@phk.freebsd.dk cc: src-committers@FreeBSD.org cc: Bosko Milekic cc: Bruce Evans cc: cvs-src@FreeBSD.org cc: Steve Kargl 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 21:23:30 -0000 Marcel Moolenaar wrote: > On Tue, Jul 22, 2003 at 01:54:16PM -0500, Alan L. Cox wrote: > > > > > > `-finline-limit=N' > > > By default, gcc limits the size of functions that can be inlined. > > > This flag allows the control of this limit for functions that are > > > explicitly marked as inline (i.e., marked with the inline keyword > > > or defined within the class definition in c++). N is the size of > > > functions that can be inlined in number of pseudo instructions > > > (not counting parameter handling). The default value of N is 600. > > > Increasing this value can result in more inlined code at the cost > > > of compilation time and memory consumption. Decreasing usually > > > > > > > There is another way. The following example illustrates its use. > > > > static int vm_object_backing_scan(vm_object_t object, int op) > > __attribute__((always_inline)); > > I hope we can come up with a scheme that allows us to control > inlining on a per-platform basis. Current events demonstrate > pretty good how people treat optimizations (which inlining is) > as machine independent fodder and how easy it is to generalize > beyond sensibility. > Unfortunately, the use of an expression-like syntax (inline or > __attribute__ keyword) makes this harder than with a statement- > like syntax (like #pragma), because of the 2-D space (platforms > vs functions). Sure, but we're also limited by what the compiler provides. gcc should probably provide #pragma hooks as a way to set the equivalent of things like 'cc --param max-inline-insns-single=2400', but as far as I'm aware, it doesn't. For what its worth, if we use __attribute__((always_inline)), it should be #define __always_inline__ __attribute__((__always_inline__)) and declare functions as int foo(int bar) __always_inline__; so that we can avoid embedding more gcc-isms in such a way that isn't trivial to #define away. Cheers, -Peter -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5