Re: refactor architecture-specific popcount code - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: refactor architecture-specific popcount code
Date
Msg-id aYy-snFaNjOxejn1@nathan
Whole thread Raw
In response to Re: refactor architecture-specific popcount code  (John Naylor <johncnaylorls@gmail.com>)
Responses Re: refactor architecture-specific popcount code
List 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

pgsql-hackers by date:

Previous
From: Zsolt Parragi
Date:
Subject: Re: Improving GUC prefix ownership for extensions
Next
From: Yasir
Date:
Subject: Regression failures after changing PostgreSQL blocksize