Horton

Re: refactor architecture-specific popcount code

Heikki Linnakangas <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: John Naylor <johncnaylorls@gmail.com>, pgsql-hackers@postgresql.org
Date: 2026-01-15T18:02:31Z
Lists: pgsql-hackers 
On 15/01/2026 18:08, Nathan Bossart wrote:
> On Thu, Jan 15, 2026 at 11:42:14AM +0200, Heikki Linnakangas wrote:
>> Yeah, I noticed that on x86_64, pg_popcount_optimized is always a function
>> pointer with runtime check, even if you use compiler flags to target a CPU
>> where the special instructions are available unconditionally.
> 
> I wonder how close we are to being able to just require SSE4.2/POPCNT for
> x86-64 builds.  I suppose there's always a chance that someone will try to
> run Postgres 19 on a CPU from the aughts...  In any case, avoiding the
> function pointer when possible seems like a good follow-up.

It's not really our decision. Packagers choose which architecture to 
target and which compiler options to build with. We ought to just 
respect those choices.

- Heikki

Commits

  1. Make use of pg_popcount() in more places.

  2. Remove uses of popcount builtins.

  3. Remove some unnecessary optimizations in popcount code.

  4. Remove specialized word-length popcount implementations.

  5. Move x86-64-specific popcount code to pg_popcount_x86.c.

  6. Refactor some SIMD and popcount macros.

  7. Rename "fast" and "slow" popcount functions.

  8. Rename pg_popcount_avx512.c to pg_popcount_x86.c.

  9. Remove trailing zero words from Bitmapsets

  10. Don't use _BitScanForward64/_BitScanReverse64 on 32-bit MSVC builds