From owner-cvs-all@FreeBSD.ORG Tue Jul 22 10:47:32 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 BA96837B405; Tue, 22 Jul 2003 10:47:32 -0700 (PDT) Received: from HAL9000.homeunix.com (ip114.bella-vista.sfo.interquest.net [66.199.86.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id B13A343F3F; Tue, 22 Jul 2003 10:47:31 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.9/8.12.9) with ESMTP id h6MHlRhC008562; Tue, 22 Jul 2003 10:47:27 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.9/8.12.9/Submit) id h6MHlLAR008561; Tue, 22 Jul 2003 10:47:21 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 22 Jul 2003 10:47:21 -0700 From: David Schultz To: Poul-Henning Kamp Message-ID: <20030722174721.GA8358@HAL9000.homeunix.com> Mail-Followup-To: Poul-Henning Kamp , Bruce Evans , Paul Richards , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <20030722163007.GA6080@HAL9000.homeunix.com> <13094.1058892140@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13094.1058892140@critter.freebsd.dk> cc: Paul Richards cc: cvs-src@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG cc: Bruce Evans Subject: Re: cvs commit: src/sys/dev/lnc if_lnc.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 17:47:33 -0000 On Tue, Jul 22, 2003, Poul-Henning Kamp wrote: > In message <20030722163007.GA6080@HAL9000.homeunix.com>, David Schultz writes: > > >The cost of not inlining is insignificant on i386, but it can be > >very significant on architectures with sliding register windows, > >such as sparc64. On sparc64, a trap is taken every time the > >procedure call depth changes by more than 6. An inlining can mean > >the difference between super-efficient procedure calls and having > >to slide the register window back and forth at great penalty. > > Fine, but if you are not able to measure the difference and the > code is bigger, is it worth it ? Inlining C++ code on sparc64 is a huge win, but that's mostly because C++ is very heavy on function calls. I don't know exactly what the impact would be on most parts of the FreeBSD kernel. > >[1] In practice, just about any contentious case of inlining is > > going to be a wash anyway, and neither side of the argument > > is entirely without merit. I'm mostly opposed to a new policy > > on the grounds that it's just another stupid rule, complete > > with technicolor bikesheds, to throw in the faces of people > > trying to do something useful. > > I far prefer to just fix the problems, but clearly the sort of > inline (and register) use we have in the tree indicates that at > least some of our contributors are in need of a guideline for > when to inline things. If you want to add a few lines to style(9) to the effect of ``be careful, inlining allows you to shoot yourself in the foot with exponentially more bullets than you expected'', that's fine with me. But I'd rather see inlines fixed or complained about only when someone really did screw up. I worry that if people are prevented from using inlines, they will not decompose their code into separate functions as much in the first place, regardless of whether the optimization was justified. If the inline doesn't increase code size, it is certainly the lesser of two evils, and, in my opinion, not worth fussing about.