Re: refactor architecture-specific popcount code

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: John Naylor <johncnaylorls(at)gmail(dot)com>
Cc: Greg Burd <greg(at)burd(dot)me>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: refactor architecture-specific popcount code
Date: 2026-02-11 17:38:58
Message-ID: aYy-snFaNjOxejn1@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v13-0001-Remove-some-unnecessary-optimizations-in-popcoun.patch text/plain 5.5 KB
v13-0002-Remove-specialized-word-length-popcount-implemen.patch text/plain 10.9 KB
v13-0003-Remove-uses-of-popcount-builtins.patch text/plain 6.3 KB
v13-0004-Convert-some-popcount-functions-to-macros.patch text/plain 3.0 KB
v13-0005-Make-use-of-pg_popcount-in-more-places.patch text/plain 3.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yasir 2026-02-11 18:19:37 Regression failures after changing PostgreSQL blocksize
Previous Message Zsolt Parragi 2026-02-11 17:19:25 Re: Improving GUC prefix ownership for extensions