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 1gu9W8-0004CY-Q0 for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Feb 2019 05:25:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gu9W7-0008KL-DG for pgsql-hackers@arkaria.postgresql.org; Thu, 14 Feb 2019 05:24:59 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gu9W7-0008KD-66 for pgsql-hackers@lists.postgresql.org; Thu, 14 Feb 2019 05:24:59 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gu9W5-0007ol-5Y for pgsql-hackers@lists.postgresql.org; Thu, 14 Feb 2019 05:24:58 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x1E5OowM016169; Thu, 14 Feb 2019 00:24:50 -0500 From: Tom Lane To: Thomas Munro cc: Alvaro Herrera , Andrew Gierth , David Rowley , PostgreSQL Hackers Subject: Re: Using POPCNT and other advanced bit manipulation instructions In-reply-to: <14024.1550119448@sss.pgh.pa.us> References: <20190213221719.GA15976@alvherre.pgsql> <26998.1550097202@sss.pgh.pa.us> <27185.1550097476@sss.pgh.pa.us> <11319.1550115484@sss.pgh.pa.us> <14024.1550119448@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 13 Feb 2019 23:44:08 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <16167.1550121890.1@sss.pgh.pa.us> Date: Thu, 14 Feb 2019 00:24:50 -0500 Message-ID: <16168.1550121890@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Some further thoughts here ... Does the "lzcnt" runtime probe actually do anything useful? On the x86_64 compilers I tried (gcc 8.2.1 and 4.4.7), __builtin_clz and __builtin_ctz compile to sequences involving bsrq and bsfq regardless of -mpopcnt. It's fairly hard to see how lzcnt would buy anything over those sequences even if there were zero overhead involved in using it. Alvaro noted that the test programs used by c-compiler.m4 fail to produce any actual code involving the builtin, because of compile-time constant folding. This seems pretty unwise. I see that on my x86_64 compilers, without -mpopcnt, __builtin_popcnt compiles to a call of some libgcc function or other. It's conceivable that on an (arguably misconfigured) platform, these c-compiler.m4 tests would pass yet the build fails at link because libgcc lacks the needed infrastructure. These tests should be coded in a way that doesn't allow the call to be optimized away -- cf comments for PGAC_C_BUILTIN_OP_OVERFLOW. Also, it's starting to seem like we have enough probes for compiler builtins that we should fold them to use one set of infrastructure. There are some like __builtin_constant_p that probably do need their own custom tests, but these ones that just verify that a call compiles seem pretty duplicative ... regards, tom lane