From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Andrew Gierth <andrew@tao11.riddles.org.uk>,
        David Rowley <david.rowley@2ndquadrant.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
        Thomas Munro <thomas.munro@enterprisedb.com>
Subject: Re: Using POPCNT and other advanced bit manipulation instructions
In-reply-to: <20190213221719.GA15976@alvherre.pgsql>
References: <20190213221719.GA15976@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Wed, 13 Feb 2019 19:17:19 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <26997.1550097202.1@sss.pgh.pa.us>
Date: Wed, 13 Feb 2019 17:33:22 -0500
Message-ID: <26998.1550097202@sss.pgh.pa.us>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> and we have defined pg_popcount64() like this:

> static int
> pg_popcount64_sse42(uint64 word)
> {
> 	return __builtin_popcountl(word);
> }

That is clearly completely broken.


> 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().

AFAICS, this is a gcc-ism, and it looks like they've probably had
all width variants for the same amount of time.  I'd take out the
test for __builtin_popcountl(), and assume that testing for
__builtin_popcount() is sufficient until proven differently.

			regards, tom lane