Re: Using POPCNT and other advanced bit manipulation instructions

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, 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>
Subject: Re: Using POPCNT and other advanced bit manipulation instructions
Date: 2019-02-14 04:20:19
Message-ID: CAEepm=0eyotC0jjVuX90vY2myxRodspDqfrBLa6hOS_MPFQyuQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 14, 2019 at 4:38 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> And, while I'm complaining: why the devil is use of the compiler builtins
> gated by HAVE__GET_CPUID? This is unbelievably Intel-centric, because
> it prevents use of the builtins on other architectures. If the builtin
> exists, we should use it, full stop. There's no reason to expect that it
> would be slower than hand-rolled code, regardless of the architecture.

FWIW a quick test of __builtin_popcount(n) compiles as CNT on a Debian
ARM system, without any special compiler flags.

> I'd be inclined to rip out all of the run-time-detection logic here;
> I doubt any of it is buying anything that's worth the price of an
> indirect call.

No view on that but apparently there were Intel Atom and AMD C chips
sold in the early part of this decade that lack POPCNT so I suspect
the distros can't ship software that requires it with no fallback.

--
Thomas Munro
http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-02-14 04:44:08 Re: Using POPCNT and other advanced bit manipulation instructions
Previous Message Michael Paquier 2019-02-14 04:04:45 Re: pg_basebackup ignores the existing data directory permissions