From owner-svn-src-head@FreeBSD.ORG Sat Mar 21 00:55:03 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 534FC1B1; Sat, 21 Mar 2015 00:55:03 +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 E66E180C; Sat, 21 Mar 2015 00:55:02 +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 t2L0suuA008302 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 21 Mar 2015 02:54:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t2L0suuA008302 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t2L0su79008301; Sat, 21 Mar 2015 02:54:56 +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 02:54:56 +0200 From: Konstantin Belousov To: Bruce Evans Subject: Re: svn commit: r280279 - head/sys/sys Message-ID: <20150321005456.GC2379@kib.kiev.ua> References: <201503201027.t2KAR6Ze053047@svn.freebsd.org> <20150320130216.GS2379@kib.kiev.ua> <20150321085923.U1046@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150321085923.U1046@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 00:55:03 -0000 On Sat, Mar 21, 2015 at 09:42:51AM +1100, Bruce Evans wrote: > On Fri, 20 Mar 2015, Konstantin Belousov wrote: > > > On Fri, Mar 20, 2015 at 10:27:06AM +0000, John Baldwin wrote: > >> Author: jhb > >> Date: Fri Mar 20 10:27:06 2015 > >> New Revision: 280279 > >> URL: https://svnweb.freebsd.org/changeset/base/280279 > >> > >> Log: > >> Expand the bitcount* API to support 64-bit integers, plain ints and longs > >> and create a "hidden" API that can be used in other system headers without > >> adding namespace pollution. > >> - If the POPCNT instruction is enabled at compile time, use > >> __builtin_popcount*() to implement __bitcount*(), otherwise fall back > >> to software implementations. > > > Are you aware of the Haswell errata HSD146 ? I see the described behaviour > > I wasn't. > > > on machines back to SandyBridge, but not on Nehalems. > > HSD146. POPCNT Instruction May Take Longer to Execute Than Expected > > Problem: POPCNT instruction execution with a 32 or 64 bit operand may be > > delayed until previous non-dependent instructions have executed. > > If it only affects performance, then it is up to the compiler to fix it. It affects performance on some cpu models. It is too wrong for compiler to issue cpuid before popcnt. Always issuing xorl before popcnt, as it is currently done by recent gcc, but not clang, is better, but still I think it is up to the code author to decide. > > > 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. > > IIRC, then patch never never uses asm, but intentionally uses the popcount > builtin to avoid complications. > > >> - Use the existing bitcount16() and bitcount32() from to > >> implement the non-POPCNT __bitcount16() and __bitcount32() in > >> . > > Why is it in sys/types.h ? > > To make it easier to use, while minimizing namespace pollution and > inefficiencies. Like the functions used to implement ntohl(), except > the implementation is MI so it doesn't need to be in . > (The functions used to implement ntohl() are in machine/endian.h. > sys/types.h always includes that, so it makes little difference to > pollution and inefficiency that the implementation is not more directly > in machine/_types.h.) bitcount is simpler and not burdened by > compatibility, so it doesn't need a separate header.) Still, it is weird to provide functions from the sys/types.h namespace, and even more weird to provide such special-purpose function.