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

From John Naylor
Subject Re: refactor architecture-specific popcount code
Date
Msg-id CANWCAZZkp2_wP3Dd1p_cVqWyXuJYL7wCMHSQL4p-m-cy0iwHAg@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 Wed, Feb 11, 2026 at 1:45 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> On Sat, Feb 07, 2026 at 03:54:31PM +0700, John Naylor wrote:
> > Okay, this is looking good. I have just one more suggestion: For 0002,
> > just copy the word-wise functions verbatim. That way, it's a pure
> > refactoring commit and the exception doesn't need explaining. With
> > that, I'd say go ahead and commit 0001/2.
>
> Seems reasonable.  Here is an updated patch set.  I've also swapped 0003
> and 0004.

0002: I just noticed another thing that could be done in a separate
follow-up patch:

@@ -220,17 +170,6 @@ pg_popcount_masked_portable(const char *buf, int
bytes, bits8 mask)
  * actual external functions.  The compiler should be able to inline the
  * portable versions here.
  */
-int
-pg_popcount32(uint32 word)
-{
-   return pg_popcount32_portable(word);
-}

The last sentence doesn't seem to be true anymore for the functions
that remain here:

(Needed to add "#undef HAVE_X86_64_POPCNTQ" in a few places to demonstrate)
objdump --no-show-raw-insn --no-addresses -drwC -M intel
/path/to/postgres | grep -C 5 pg_popcount_portable

<pg_popcount_optimized>:
        jmp    <pg_popcount_portable>

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.

--
John Naylor
Amazon Web Services

Attachment

pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Do we still need MULE_INTERNAL?
Next
From: Pierre Ducroquet
Date:
Subject: Re: llvmjit - improve code generated in O0