Re: centralize CPU feature detection - Mailing list pgsql-hackers

From John Naylor
Subject Re: centralize CPU feature detection
Date
Msg-id CANWCAZZez5TX2fQH8Q_K312TC97O-dMQWJPUtLLGQRNBbcYuSQ@mail.gmail.com
Whole thread Raw
In response to Re: centralize CPU feature detection  (Zsolt Parragi <zsolt.parragi@percona.com>)
Responses Re: centralize CPU feature detection
List pgsql-hackers
On Thu, Feb 19, 2026 at 1:47 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
>
> > Done. I haven't tried Arm support yet, but now I realize the header
> > should be named generically, so it's now "pg_cpu.h". Then it can be
> > included everywhere.
>
> That makes sense, and simplifies the usage of the header. (However,
> the include guard still refers to the old name)

Oops, fixed.

> > I don't know. The instruction family names are conventionally all in
> > caps, but this is just our signal that we've populated the array. That
> > said, a less generic name would better for grep-ability.
>
> Yes, that could work too. But reserving the lowercase "init" symbol in
> a very generic header seems like a bad idea (especially for a use case
> that isn't used globally), even if Postgres itself doesn't use the
> symbol for anything else. "INIT" at least would be unlikely to
> conflict with something else.

Still seems pretty generic, so I went with INIT_PG_X86.

I've also made a quick attempt at Arm support just to make sure I
didn't paint myself into a corner (v4-0005-6), and it compiles and
passes tests on a Debian aarch64 system with gcc 8.3. I'll put that
aside for later. v4-0001-3 are still the main focus now, and seem in
decent shape, maybe needs a bit more polish. (not to mention formal
commit messages)

--
John Naylor
Amazon Web Services

Attachment

pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Adding locks statistics
Next
From: Amit Kapila
Date:
Subject: Re: Skipping schema changes in publication