agora inbox for pgsql-committers@postgresql.org
help / color / mirror / Atom feedFrom: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-committers@lists.postgresql.org
Subject: pgsql: Clean up inconsistencies in CPU-identification macros.
Date: Tue, 30 Jun 2026 16:21:13 +0000
Message-ID: <E1webCz-000nPm-2B@gemulon.postgresql.org> (raw)
Clean up inconsistencies in CPU-identification macros.
In various places we depend on compiler-defined macros like __x86_64__
to guard CPU-type-specific code. However, those macros aren't very
well standardized; in particular, it emerges that MSVC doesn't define
any of the ones gcc does, but has its own. We were not coping with
that consistently, with the result that we're missing some useful
CPU-dependent optimizations in MSVC builds. There are also some
places that are checking randomly-different spellings that may
have been the only ones recognized by some old compilers, but we
weren't doing that consistently either.
Let's standardize on using gcc's long-form spellings (with trailing
underscores), after putting a stanza into c.h that ensures that these
spellings are defined even when the compiler provides some other one.
I put an "#else #error" branch into the c.h addition so that we'll
get an error if the compiler provides none of the symbols we're
expecting. That might be best removed in the end, since it might
annoy people trying to port to some new CPU type. But for testing
this it seems like a good idea, in case we've missed some common
variant spelling.
In addition to enabling some optimizations we previously missed on
MSVC, this cleans up a thinko. Several places used "_M_X64" in the
apparent belief that that's MSVC's equivalent to __x86_64__, but
it's not: it will also get defined on some but not all ARM64 builds.
Also, guard the x86_feature_available() stuff in pg_cpu.[hc] with
#if defined(__x86_64__) || defined(__i386__)
which seems like a more natural way of specifying what it applies to.
This builds on some previous work by Thomas Munro, but it requires
much less code churn because it re-uses gcc's names for the CPU-type
macros instead of inventing our own.
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/CA+hUKGL8Hs-phHPugrWM=5dAkcT897rXyazYzLw-Szxnzgx-rA@mail.gmail.com
Discussion: https://postgr.es/m/3035145.1780503430@sss.pgh.pa.us
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/2ef57e636fc97528a37515673f5f56a1fcf97186
Modified Files
--------------
src/common/d2s.c | 2 +-
src/include/c.h | 58 +++++++++++++++++++++++++++++++++++-
src/include/port/atomics.h | 6 ++--
src/include/port/atomics/arch-x86.h | 4 +--
src/include/port/pg_bitutils.h | 4 +--
src/include/port/pg_cpu.h | 4 +--
src/include/portability/instr_time.h | 2 +-
src/include/storage/s_lock.h | 10 +++----
src/port/pg_cpu_x86.c | 6 ++--
9 files changed, 76 insertions(+), 20 deletions(-)
Message-ID: <E1webCz-000nPm-2B@gemulon.postgresql.org>
Permalink: ../E1webCz-000nPm-2B@gemulon.postgresql.org/
Also on: postgresql.org/message-id/E1webCz-000nPm-2B@gemulon.postgresql.org
reply
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-committers@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Clean up inconsistencies in CPU-identification macros.
In-Reply-To: <E1webCz-000nPm-2B@gemulon.postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox