From owner-cvs-src@FreeBSD.ORG Tue Jul 22 14:30:30 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAA0F37B405; Tue, 22 Jul 2003 14:30:29 -0700 (PDT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC72243FA3; Tue, 22 Jul 2003 14:30:28 -0700 (PDT) (envelope-from peter@wemm.org) Received: from wemm.org (localhost [127.0.0.1]) by canning.wemm.org (Postfix) with ESMTP id 76A9E2A7EA; Tue, 22 Jul 2003 14:30:28 -0700 (PDT) (envelope-from peter@wemm.org) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Alan L. Cox" In-Reply-To: <3F1DA5B9.A877E8D9@imimic.com> Date: Tue, 22 Jul 2003 14:30:28 -0700 From: Peter Wemm Message-Id: <20030722213028.76A9E2A7EA@canning.wemm.org> 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 cc: Marcel Moolenaar 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-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 21:30:30 -0000 "Alan L. Cox" wrote: > 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. Yes, your suspicion is correct. It does its estimation before any optimization, dead code elimination, etc. Alexander mentioned the exact way it does it, but its something like "instruction_estimate = (number of C keywords + some parser stuff) * 10".. so all the do { } while (0) stuff counts as ~100 instructions in the estimate. A KOBJ call is estimated at (I think Alexander mentioned) 571 instructions instead of a couple. The bad thing here is that since ~gcc-3.1, all these inlines have been silently turned off without warning. This might explain some of the stack issues with kobj/newbus/etc on the expensive function call architectures. 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