| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | John Naylor <johncnaylorls(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: refactor architecture-specific popcount code |
| Date: | 2026-01-15 16:08:16 |
| Message-ID: | aWkQ8AB9WlWVEEfe@nathan |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Antonin Houska | 2026-01-15 16:36:59 | Re: Adding REPACK [concurrently] |
| Previous Message | Euler Taveira | 2026-01-15 16:07:26 | Re: log_min_messages per backend type |