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: John Naylor <johncnaylorls@gmail.com>
Cc: Greg Burd <greg@burd.me>, Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-02-11T17:38:58Z
Lists: pgsql-hackers

Attachments

On Wed, Feb 11, 2026 at 02:10:37PM +0700, John Naylor wrote:
> I don't think we need to worry about this, but the attached looks
> nicer to me. There might be a disadvantage of using macros here, but
> I'm not sure what it would be.

The only problem that I see with this is that a compiler that understands
Neon intrinsics but not SVE ones will probably fail because we build
external functions that call the Neon versions in that case.  But that's
easy enough to work around by adding an extra #elif defined(USE_NEON)
section, and it still saves a handful of lines of code.  Perhaps someday
this situation will be rare enough that we can remove that hack and just
point to the portable versions if the compiler doesn't understand both Neon
and SVE, but I'm not sure we're there yet.

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