Date: Tue, 22 Jul 2003 14:23:28 -0700 From: Peter Wemm <peter@wemm.org> To: Marcel Moolenaar <marcel@xcllnt.net> 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: <20030722212328.EF8DB2A8B2@canning.wemm.org> In-Reply-To: <20030722201918.GA1052@athlon.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030722212328.EF8DB2A8B2>