From owner-svn-src-head@FreeBSD.ORG Sat Mar 21 14:23:28 2015 Return-Path: Delivered-To: svn-src-head@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 BFE5495D; Sat, 21 Mar 2015 14:23:28 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 60AC1C8B; Sat, 21 Mar 2015 14:23:28 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t2LENI7T000238 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Mar 2015 16:23:18 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2LENI7T000238 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2LENIci000237; Sat, 21 Mar 2015 16:23:18 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Mar 2015 16:23:18 +0200 From: Konstantin Belousov To: Bruce Evans Subject: Re: svn commit: r280279 - head/sys/sys Message-ID: <20150321142318.GI2379@kib.kiev.ua> References: <201503201027.t2KAR6Ze053047@svn.freebsd.org> <20150320130216.GS2379@kib.kiev.ua> <20150321085923.U1046@besplex.bde.org> <20150321005456.GC2379@kib.kiev.ua> <20150321205449.H1846@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150321205449.H1846@besplex.bde.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, John Baldwin X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 14:23:29 -0000 On Sat, Mar 21, 2015 at 09:33:22PM +1100, Bruce Evans wrote: > On Sat, 21 Mar 2015, Konstantin Belousov wrote: > How does the unconditional use of popcntq (in inline asm that is called > from amd64 pmap) even work? It is not unconditional. The pmap code does the following: if ((cpu_feature2 & CPUID2_POPCNT) == 0) { free = popcnt_pc_map_elem(pc->pc_map[0]); ... } else { free = popcntq(pc->pc_map[0]); ... } > > jhb's cleanups apparently missed this inline asm, while previous work > should not have added it. This inline asm should never have existed, > since compilers can generate the same code with less-incorrect > configuration. Correct configuration would be messy. jhb's cleanups > depend on a compiler predefine (__POPCNT__) to determine if the > instruction can be used. But this definition is static and is usually > wrong, since compilers default to plain amd64 which doesn't have the > instruction. Dynamic configuration would have to use cpuid just to > determine if the instruction exists. Exactly, this is what supposed to be done, and is done in the pmap. It is fine for somebody targeting specific machine to change -march, but it cannot be used to optimize the generic kernel which is shipped. > > >>> Jilles noted that gcc head and 4.9.2 already provides a workaround by > >>> xoring the dst register. I have some patch for amd64 pmap, see the end > >>> of the message. > > I thought that that couldn't work since it uses the instruction > unconditionally. But the old code already does that. > > >> IIRC, then patch never never uses asm, but intentionally uses the popcount > >> builtin to avoid complications. > > popcntq() in amd64/include/cpufunc.h does use asm, but is missing the > complications needed for when it the instruction is not available. > All callers (just 3 in pmap) seem to be broken, since they are also > missing the complications. See above. > > Still, it is weird to provide functions from the sys/types.h namespace, > > and even more weird to provide such special-purpose function. > > Not in the sys/types.h, but in the implementation namespace :-). Since > no one should depend on the implementation details, we can move the > details to a better place when one is known. Better places would be > something like libkern for userland to hold a large collection of > functions, and a Standard place for single functions. I expect the > Standard place will be broken as designed for compatibility. Probably > strings.h alongside ffs(). strings.h sounds less surprising than sys/types.h > > The special (inline/asm) functions are in sys/types.h on amd64 are > currently limited to just 3 bswap functions and some new popcnt functions.