Re: Using POPCNT and other advanced bit manipulation instructions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Subject: Re: Using POPCNT and other advanced bit manipulation instructions
Date: 2019-02-13 22:33:22
Message-ID: 26998.1550097202@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-13 22:37:56 Re: Using POPCNT and other advanced bit manipulation instructions
Previous Message Alvaro Herrera 2019-02-13 22:17:19 Re: Using POPCNT and other advanced bit manipulation instructions