From: Nathan Bossart <nathandbossart@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: John Naylor <johncnaylorls@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: refactor architecture-specific popcount code
Date: Thu, 15 Jan 2026 10:08:16 -0600
Message-ID: <aWkQ8AB9WlWVEEfe@nathan> (raw)
In-Reply-To: <e67ca6d9-db0b-4322-97ca-176964b94a35@iki.fi>
References: <aWf_InS1VrbeXAfP@nathan>
<CANWCAZb0U2qDTHCxPDyZugOTSE7xPURWKwcf8d4JmYTgH4+nEA@mail.gmail.com>
<e67ca6d9-db0b-4322-97ca-176964b94a35@iki.fi>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nathandbossart@gmail.com, hlinnaka@iki.fi, johncnaylorls@gmail.com
Subject: Re: refactor architecture-specific popcount code
In-Reply-To: <aWkQ8AB9WlWVEEfe@nathan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox