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

From John Naylor
Subject Re: refactor architecture-specific popcount code
Date
Msg-id CANWCAZY797DGVsPYmPXutERwAMUMdDT12B8NjCrJU7SLxqmjhA@mail.gmail.com
Whole thread Raw
In response to Re: refactor architecture-specific popcount code  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: refactor architecture-specific popcount code
List pgsql-hackers
On Thu, Feb 12, 2026 at 12:39 AM Nathan Bossart
<nathandbossart@gmail.com> wrote:
>
> 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.

Ah, right.

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

I have a better idea, but it depends on re-thinking feature detection
and compile-time vs run-time checks, and that's not quite ready to
share, so let's shelve this for now.

Anyway, I think 0001 and 0002 are ready for commit.

--
John Naylor
Amazon Web Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Odd usage of errmsg_internal in bufmgr.c
Next
From: Pavel Stehule
Date:
Subject: Re: plpgsql: variables of domain of composite types are not correctly initialized