From owner-svn-src-all@FreeBSD.ORG Thu Dec 4 19:19:06 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 062FDBF6; Thu, 4 Dec 2014 19:19:06 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D34547A0; Thu, 4 Dec 2014 19:19:05 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id sB4JJ47t026062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2014 11:19:04 -0800 (PST) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id sB4JJ4T7026061; Thu, 4 Dec 2014 11:19:04 -0800 (PST) (envelope-from jmg) Date: Thu, 4 Dec 2014 11:19:04 -0800 From: John-Mark Gurney To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Subject: Re: svn commit: r275468 - head/sys/dev/usb/controller Message-ID: <20141204191904.GB25139@funkthat.com> References: <201412032155.sB3LtjJN043364@svn.freebsd.org> <20141204005451.GM99957@funkthat.com> <54800B60.9020208@selasky.org> <20141204175032.GQ99957@funkthat.com> <86sigve0c0.fsf@nine.des.no> <201412032155.sB3LtjJN043364@svn.freebsd.org> <20141204005451.GM99957@funkthat.com> <1373EB55-4238-40D0-B481-53C8B46D6E6C@FreeBSD.org> <86wq67e3y8.fsf@nine.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86sigve0c0.fsf@nine.des.no> <86wq67e3y8.fsf@nine.des.no> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Thu, 04 Dec 2014 11:19:04 -0800 (PST) Cc: Hans Petter Selasky , src-committers@freebsd.org, Hans Petter Selasky , svn-src-all@freebsd.org, Dimitry Andric , svn-src-head@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 19:19:06 -0000 Dag-Erling Smrgrav wrote this message on Thu, Dec 04, 2014 at 19:28 +0100: > John-Mark Gurney writes: > > Did you see the comment about usig __builtin_ffs{,l,ll} instead? this > > seems to be a better route... > > No. It's needlessly compiler-dependent. I'm confused, in an earlier email you said: Dag-Erling Smrgrav wrote this message on Thu, Dec 04, 2014 at 18:10 +0100: > Dimitry Andric writes: > > Maybe it is easier to alias ffs() and friends to __builtin_ffs(), > > since the compilers we support have these builtins already. > > That should already be the case on platforms that support it. There is > absolutely no reason to hand-roll an ffs() equivalent. So this says that you think it should be using the builtin, yet when I suggested it, you say no? Which is it? Yes, it is compiler dependant, and yes, we are getting closer to supporting external tool chains, but I doubt that the external tool chain is going to be anything other than gcc or clang, which both support all three... If someone does want to add a compiler that doesn't support it, it's easy enough for them to add an ifdef or two and add the proper code... Considering that we have hacks like: #ifdef HAVE_INLINE_FFSL cpu = CPU_FFS(&cpumask) - 1; #else while (cpu >= 0 && !CPU_ISSET(cpu, &cpumask)) cpu--; #endif in sched_ule.c, switching to always using builtin ffs and getting ride of these hacks seems like the best choice... If people feel that they need to implement ffs themselves, then we clearly aren't doing our job of providing fast blocks to build upon... > > So, how about changing libkern.h to define the various ones to the > > built in, and dropping all the special versions? > > This is (or should) be taken care of in cpufunc.h for platforms that > support ffs / fls in hardware. Considering that I'd trust the compiler writers to optimize their code more than the people who port to a new platform, I disagree... Rarely do ports to a new platform back fill in support functions like these, yet clearly, they are important, since mav thought it important enough to hack sched_ule.c... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."