Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gu2qO-0005kC-JA for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Feb 2019 22:17:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gu2qN-0003w4-8n for pgsql-hackers@arkaria.postgresql.org; Wed, 13 Feb 2019 22:17:27 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gu2qM-0003q1-PM for pgsql-hackers@lists.postgresql.org; Wed, 13 Feb 2019 22:17:27 +0000 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gu2qJ-0003HG-Cx for pgsql-hackers@lists.postgresql.org; Wed, 13 Feb 2019 22:17:25 +0000 Received: by mail-qt1-x842.google.com with SMTP id z39so4656326qtz.0 for ; Wed, 13 Feb 2019 14:17:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=LuIbAF3v73WTBz1xvjRHCkBPzD2e5trgV8/bbjZbL6Q=; b=xfsoh1tsjomQ9l4Lmguw7Wq8WI9XR/ijSzE+dyjbRdI/PagI8cq/yeqqqryu44uZWU aqkUbuncSlvhwCI8ay3xCas1tgaPBg/5iLNDs8du10DzBdyYziY5UaBxDXGNISIKQihT LgrnWRL6tnB8pnOxTRmEVXt9ih+VJZpgQBNfSv+K2AfBTjoqBdDk/AFjt8O+2MtO/5rJ URWs+diE0WAwJhcKOr5KHZ+VEJZv8J+yRc+3mp01hX0ePcxKmLlJ/B6AaUnXOSWnrnD5 Yzi0qCBQsLoW6Q7+9Fgign7dHOeBWVsOwqDF7P1jXPgYCm86S9CEJIxdyiVAH28etK5Q Jlqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=LuIbAF3v73WTBz1xvjRHCkBPzD2e5trgV8/bbjZbL6Q=; b=dNVDfO4/+kRX9wlEswQbDUYaVSIN3NW7vOJhtuL1GetKK4+3OwPd0wSagZkAmiE3R4 dZo16VBTZkm+R6rXFsXeo+tLHRKIlYgm5BlW7LTnociTmoxkhTDviA9fIkI6UstbhByZ wwYvT89ZqLAYxFW58WFkYTWFltmB812Bqma2MxzYpioGeoyNQ1l+35IZ3/gZ96VEjrdL KQULR/wH3oH7n4UYtFIK5XVC/8o7jJBnJMtRaSP+sHa4uVI4zMkg3PlY0yg8aJOWqTzz p43csmQB/B3rUfv34zrOGCYY/6lPnjotKiwKivLFsPKmkkn554Ctuog9rVjUO6zTSzVP ctnQ== X-Gm-Message-State: AHQUAubr0PcOHg13vjmTm/swxvRcdJpTMWv6kxx7W/Xhh3ZbJA98HDMX gUbAJs5v1vZV4FU6fZnBHYgALg== X-Google-Smtp-Source: AHgI3IbPVOdbMt19b3TL3Cl3z35VbqMxG/1K7pjm2EJ+QuyP1WX+IVZZoE8vDsVW0Ba2BF3WJaLNsw== X-Received: by 2002:ac8:24f2:: with SMTP id t47mr399727qtt.120.1550096242579; Wed, 13 Feb 2019 14:17:22 -0800 (PST) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id i20sm390326qta.19.2019.02.13.14.17.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 13 Feb 2019 14:17:21 -0800 (PST) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id EB932124264; Wed, 13 Feb 2019 19:17:19 -0300 (-03) Date: Wed, 13 Feb 2019 19:17:19 -0300 From: Alvaro Herrera To: Andrew Gierth Cc: David Rowley , PostgreSQL Hackers , Thomas Munro Subject: Re: Using POPCNT and other advanced bit manipulation instructions Message-ID: <20190213221719.GA15976@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="C7zPtVaVf+AK4Oqc" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190213205904.GA13925@alvherre.pgsql> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --C7zPtVaVf+AK4Oqc Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2019-Feb-13, Alvaro Herrera wrote: > It definitely is ... plans have changed from using IndexOnly scans to > Seqscans, which is likely fallout from the visibilitymap_count() change. I think the problem here is that "unsigned long" is 32 bits in this machine: checking whether long int is 64 bits... no and we have defined pg_popcount64() like this: static int pg_popcount64_sse42(uint64 word) { return __builtin_popcountl(word); } so it's counting bits in the lower half of the uint64. If that's correct, then I think we need something like this patch. But it makes me wonder whether we need a configure test for __builtin_popcountll() and friends. I wonder if there's any compiler that implements __builtin_popcountl() but not __builtin_popcountll() ... and if not, then the test for __builtin_popcountl() should be removed, and have everything rely on the one for __builtin_popcount(). -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services --C7zPtVaVf+AK4Oqc Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="uint64-is-longlong.patch" diff --git a/src/port/pg_bitutils.c b/src/port/pg_bitutils.c index 97422e05040..fe6afb9fba5 100644 --- a/src/port/pg_bitutils.c +++ b/src/port/pg_bitutils.c @@ -299,7 +299,14 @@ pg_popcount64_choose(uint64 word) static int pg_popcount64_sse42(uint64 word) { +#if defined(HAVE_LONG_INT_64) return __builtin_popcountl(word); +#elif defined(HAVE_LONG_LONG_INT_64) + return __builtin_popcountll(word); +#else + /* shouldn't happen */ +#error must have a working 64-bit integer datatype +#endif } #endif @@ -407,7 +414,14 @@ pg_rightmost_one64_choose(uint64 word) static int pg_rightmost_one64_abm(uint64 word) { +#if defined(HAVE_LONG_INT_64) return __builtin_ctzl(word); +#elif defined(HAVE_LONG_LONG_INT_64) + return __builtin_ctzll(word); +#else + /* shouldn't happen */ +#error must have a working 64-bit integer datatype +#endif } #endif @@ -493,7 +507,15 @@ pg_leftmost_one64_choose(uint64 word) static int pg_leftmost_one64_abm(uint64 word) { +#if defined(HAVE_LONG_INT_64) return 63 - __builtin_clzl(word); +#elif defined(HAVE_LONG_LONG_INT_64) + return 63 - __builtin_clzll(word); +#else + /* shouldn't happen */ +#error must have a working 64-bit integer datatype +#endif + } #endif --C7zPtVaVf+AK4Oqc--