Requiring CMPXCHG16B on x86-64 systems

[Steinar H. Gunderson]

Hi,

Currently Chrome on x86-64 requires SSE3 as a minimum (and we still have some
very few systems without SSSE3). I'd like to additionally require CMPXCHG16B
support (128-bit compare-and-swap) for a lock-free hash table; Windows has
required it since 2013 (with Windows 8.1), with newer versions simply
requiring SSE4.2, which is much stricter. (Our 64-bit Arm targets, e.g.
on macOS, already have similar support AFAIK. For 32-bit systems,
the compiler simulates it using a lock.)

There are a few very old CPUs that support SSE3 but not CMPXCHG16B;
in particular, some very early Opterons and Socket 775-based Pentium 4s.
Core 2 CPUs (so that includes all Intel Macs) _do_ support it, although
some old microcode versions misidentify CPUID bits if you actually try
to go check.

So we're talking about basically some very old Linux CPUs being left out;
anything else is already on the unsupported train. The exact fraction is
unknown since we don't have telemetry for this, but we know it's bounded
upwards by the amount of systems reporting as SSE3 in UMA (all SSSE3-capable
CPUs support the instruction). Does anyone have strong opinions?

/* Steinar */
--
Homepage: https://www.sesse.net/

[Colin Blundell]

+Mark Mentovai might have input

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/hzv3vjs3srektzp7pvu5ogvr672djsj2lod3sh557dwtfpgui4%40hp6fbgqhakcm.

[Will Harris]

are you sure the cpu id is not in metrics somewhere? I note that the 32-bit signature from CPUID instruction is in https://source.chromium.org/chromium/chromium/src/+/main:third_party/metrics_proto/system_profile.proto;l=375 and seems to be reported, is that cpuid not sufficient to determine support?

In general though, it seems like if our minimum supported OS is already Windows 10, dropping support for those CPUs that Windows 10 does not seem to support seems fine. You would want to explicitly check Linux clients though, as I don't know how old we support for those.

Will

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAMGE5NFk7i-%3DxwMhRPqroh3S7tLZFfDLiwJSSYgwmt6uR0fhbA%40mail.gmail.com.

[Egor Pasko]

On Tue, Jun 30, 2026 at 10:37 AM Steinar H. Gunderson <se...@chromium.org> wrote:

Hi,

Currently Chrome on x86-64 requires SSE3 as a minimum (and we still have some
very few systems without SSSE3). I'd like to additionally require CMPXCHG16B
support (128-bit compare-and-swap) for a lock-free hash table; Windows has
required it since 2013 (with Windows 8.1), with newer versions simply
requiring SSE4.2, which is much stricter. (Our 64-bit Arm targets, e.g.
on macOS, already have similar support AFAIK. For 32-bit systems,
the compiler simulates it using a lock.)

We could implement our own fallback to a simple spinlock under !__builtin_cpu_supports("cmpxchg16b"). 

Having said that, I think those machines without cmpxchg16b are old, and it is hard to imagine productively using the modern web on those CPUs. So I would expect very low usage.

 

There are a few very old CPUs that support SSE3 but not CMPXCHG16B;
in particular, some very early Opterons and Socket 775-based Pentium 4s.
Core 2 CPUs (so that includes all Intel Macs) _do_ support it, although
some old microcode versions misidentify CPUID bits if you actually try
to go check.

So we're talking about basically some very old Linux CPUs being left out;
anything else is already on the unsupported train. The exact fraction is
unknown since we don't have telemetry for this, but we know it's bounded
upwards by the amount of systems reporting as SSE3 in UMA (all SSSE3-capable
CPUs support the instruction). Does anyone have strong opinions?

/* Steinar */
--
Homepage: https://www.sesse.net/

[Mark Mentovai]

Sorry for the delay in responding. This required a bit of focus time to research and fully answer.

x86-64

• Our Windows baseline is Windows 10, so if all supported versions of Windows 10 on x86-64 already require cmpxchg16b, then this change should be non-contentious from Chrome’s perspective. I agree that Windows on x86-64 has required cmpxchg16b since Windows 8.1, so you should be good here. Windows minimum hardware requirements → Windows 10 → (page 30, section 3.1) Processor: “Supports CMPXCHG16b, LAHF/SAHF, and PrefetchW for 64-bit OS installation” (also sections 4.1 for Windows Server 2016 and 5.1 for Windows 10 IoT Core). You can make this change with zero fanfare. We don’t need to make an announcement or change our publicly claimed system requirements.
• On macOS, our current baseline on trunk is macOS 13, which requires a 2017-era Mac at minimum. I looked up the CPU details for all of the earliest-supported x86-64 machines, and they all have a Core CPU from at least generation 7 (“Kaby Lake” architecture), vintage 2016–2017. These CPUs all absolutely support cmpxchg16b, so you should be good here too, also with zero fanfare.
• Linux will be trickier (+thomasanderson, too). Most Linux distributions on x86-64 don’t mandate any architectural extensions above the x86-64 baseline (support guaranteed only through SSE2, will run on anything back to the Prescott line of the Pentium 4 architecture, 2004.) Red Hat Enterprise Linux started requiring cmpxchg16b fairly recently  (RHEL 10, 2024-12), although that’s not a distribution we explicitly support. We do support Fedora and they have a proposal to make this a requirement, but it’s not effective yet. Debian-based distributions, including Ubuntu, are where most of our Linux desktop users are, and although this was discussed, no conclusion was reached. So in order to make this change on Linux, we’ll need to update our system requirements.

With Linux being the only question mark for x86-64, and the only CPUs losing support being the relatively narrow slice of CPUs that support SSE3 but not cmpxchg16b, I’m not opposed to making the change. We’ll want to add something about this to our enterprise release notes in advance.

arm64

The subject of the message calls out x86-64, but the body discusses arm64 as though it’s also in scope, so I’m going to cover it here too.

The original question does understand that we support mac-arm64. It misses that we also support win-arm64, and will imminently be releasing support for linux-arm64 as well. casp is the arm64 equivalent of x86-64 cmpxchg16b. The p is important: this variant atomically operates on a pair of values, and two 64-bit values together make up 128. casp is not in baseline arm64, it’s part of the FEAT_LSE (Large System Extensions) extension, mandatory in armv8.1, but optional in armv8.0 (baseline arm64).

• Windows. Chrome on win-arm64 requires Windows 11, and LSE is within Microsoft’s Windows 11 baseline requirement: Windows minimum hardware requirements → Windows 11 → (page 12, section 3.5) Processor: “Supports PF_ARM_V81_ATOMIC_INSTRUCTIONS_AVAILABLE instruction set (for ARM64 processor)” → PF_ARM_V81_ATOMIC_INSTRUCTIONS_AVAILABLE: “This Arm processor implements the Arm v8.1 atomic instructions (for example, CAS, SWP).” No problem here.
• macOS. Apple’s M-series CPUs implement armv8.4-a at minimum. As a closed system, Apple doesn’t normally publish detailed hardware information at this level, but it can be gleaned through their contributions to llvm, where apple-m1’s core is identical to apple-a14, which is defined as armv8.4-a and in fact almost armv8.5-a but for BTI’s absence. The MacBook Neo doesn’t have an M-series CPU, it’s an A18, but the A18 shares its core with M4, which is armv8.7-a or armv9.2-a depending on when you looked it up. All this is to say that LSE is fully within Apple’s baseline—it’s already enabled by default when targeting mac-arm64:

% clang --target=arm64-apple-darwin --print-enabled-extensions | grep LSE
[…]

Target: arm64-apple-darwin

[…]

    FEAT_LSE                                               Enable Armv8.1-A Large System Extension (LSE) atomic instructions
    FEAT_LSE2                                              Enable Armv8.4-A Large System Extension 2 (LSE2) atomicity rules

• Again, Linux will be a different story. Looking at a handful of Raspberry Pi boards I have running around my home, I can see that the RPi 5 boards support LSE, while the RPi 4 and RPi 3B boards do not. (You’re looking for “CPU features: detected: LSE atomic instructions” in the boot messages, such as dmesg, or “atomics” (feature test) being among the features listed in /proc/cpuinfo (“Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp” on a RPi 5.) Given that we’re looking specifically at Raspberry Pi support, I don’t think it would be wise to mandate LSE/casp support for Chrome on linux-arm64, because it would cut out Raspberry Pi 4 and older. In addition, we’ve been hearing there are many cloud-oriented uses for linux-arm64 Chrome, and I don’t expect that LSE is broadly available across cloud arm64 systems.
• I haven’t fully considered non-desktop platforms here, but it’s worth raising awareness.
• For iOS, you’d have to rewind to A10 (2016) to find a CPU that doesn’t implement LSE, and those won’t run iOS beyond iOS 15. Chrome requires iOS 18, so you’re probably fine to assume LSE. (+rohitrao)
• My guess is that we can’t assume LSE or any better than armv8.0 on Android, though. (+yfriedman)

This is non-contentious for all desktop OS–CPU combinations aside from linux-arm64. Is it feasible to assume 128-bit compare-and-exchange support on all systems except linux-arm64, and either pessimize to a less efficient sequence or do run-time feature detection there?

[Steinar H. Gunderson]

On Thu, Jul 09, 2026 at 12:50:13PM -0400, Mark Mentovai wrote:
> Sorry for the delay in responding. This required a bit of focus time to
> research and fully answer.

Thanks for the detailed answer. I am now no longer in Chrome, so someone
else will need to pick up this. I will fill in one small detail, though:

> This is non-contentious for all desktop OS–CPU combinations aside from
> linux-arm64. Is it feasible to assume 128-bit compare-and-exchange support
> on all systems except linux-arm64, and either pessimize to a less efficient
> sequence or do run-time feature detection there?

Yes, it is perfectly possible to pessimize. If the architecture we're
compiling for doesn't have native support, the compiler/runtime will emulate
the atomic for us using a library call that does “something” (possibly a
global lock, possibly runtime detection), and I've verified that the
performance is not disastrous for the case in question (at least not on
x86-64, I assume other platforms will be similar). This is done
transparently; we don't need #ifdefs or similar.