Horton

Re: refactor architecture-specific popcount code

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: John Naylor <johncnaylorls@gmail.com>, pgsql-hackers@postgresql.org
Date: 2026-01-15T16:08:16Z
Lists: pgsql-hackers 
On Thu, Jan 15, 2026 at 11:42:14AM +0200, Heikki Linnakangas wrote:
> On 15/01/2026 11:07, John Naylor wrote:
>> s/slow/generic/:
>> 
>> I'm ambivalent about this. The "slow" designation is flat-out wrong
>> since at least Power and aarch64 can emit a single instruction here
>> without prodding the compiler. On the other hand, "generic" seems
>> wrong too, since e.g. pg_popcount64_slow() has three configure symbols
>> and two compiler builtins. :-D
> 
> "fallback", or "portable" ?

I've no strong opinions, but "portable" seems reasonable to me.

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

-- 
nathan

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