From owner-cvs-all@FreeBSD.ORG Tue Jul 22 13:59:44 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 E93E237B404 for ; Tue, 22 Jul 2003 13:59:44 -0700 (PDT) Received: from mail26d.sbc-webhosting.com (mail26d.sbc-webhosting.com [216.173.237.167]) by mx1.FreeBSD.org (Postfix) with SMTP id 7F70543FAF for ; Tue, 22 Jul 2003 13:59:43 -0700 (PDT) (envelope-from alc@imimic.com) Received: from www.imimic.com (64.143.12.21)1-0799337576; Tue, 22 Jul 2003 16:59:36 -0400 (EDT) Sender: alc@FreeBSD.ORG Message-ID: <3F1DA5B9.A877E8D9@imimic.com> Date: Tue, 22 Jul 2003 15:59:37 -0500 From: "Alan L. Cox" Organization: iMimic Networking, Inc. X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Marcel Moolenaar References: <200307221024.h6MAOggG066724@repoman.freebsd.org> <20030722093443.GD58118@technokratis.com> <20030723003823.R8380@gamplex.bde.org> <20030722112901.GA59012@technokratis.com> <20030722155139.GA39123@troutmask.apl.washington.edu> <3F1D8858.670C08B2@imimic.com> <20030722201918.GA1052@athlon.pn.xcllnt.net> Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit X-Loop-Detect: 1 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 20:59:45 -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). > I chose my example very carefully... In the case of vm_object_backing_scan(), I could argue that "always inline" is correct regardless of platform. This function was written with inlining as an expectation. It looks something like this: vm_object_backing_scan(..., int op) { ... if (op == "constant #1") ... else if (op == "constant #2") ... Furthermore, all call sites pass a constant as the value for op. Consequently, if the code is inlined, all but the relevent case are removed as dead code. I also recall this idiom being used in the i386 pmap. I suspect that gcc fails to inline this code because it makes the inline vs. no-inline decision before it does dead code elimination. Regards, Alan