[PATCH 2/5] x86: Remove catomic_* locking primitives

[Uros Bizjak]

On Mon, Sep 8, 2025 at 4:18 PM Wilco Dijkstra <Wilco.Dijkstra@arm.com> wrote:
>
> Hi Uros,
>
> > > x86 didn't define __arch_c_compare_and_exchange_bool_* primitives
>
> > The referred CMP is simply due to x86 not declaring
> > catomic_compare_and_exchange_bool_acq primitive.
>
> These catomic and __arch_c_ primitives are not used anymore - see [1] which
> removes the last few cases. Also see [2] which switches atomics to compiler
> builtins. Next we can use builtin atomics for compare_and_exchange_val/bool
> and the fences - we no longer need any assembly code (or any target specific
> code) for atomics.

Yes, I am aware of your work.

After the remaining catomic_* usage is removed from the source tree,
specifically:

--cut here--
--- a/elf/dl-profile.c
+++ b/elf/dl-profile.c
@@ -553,7 +553,7 @@ _dl_mcount (ElfW(Addr) frompc, ElfW(Addr) selfpc)
       froms[newfromidx].here = &data[narcs];
       froms[newfromidx].link = tos[to_index];
       tos[to_index] = newfromidx;
-      catomic_increment (&narcs);
+      atomic_fetch_add_relaxed (&narcs, 1);
     }

   /* If we still have no entry stop searching and insert.  */
--cut here--

and

--cut here--
--- a/malloc/arena.c
+++ b/malloc/arena.c
@@ -841,11 +841,11 @@ arena_get2 (size_t size, mstate avoid_arena)
          enough address space to create that many arenas.  */
       if (__glibc_unlikely (n <= narenas_limit - 1))
         {
[...]
             goto repeat;
           a = _int_new_arena (size);
   if (__glibc_unlikely (a == NULL))
-            catomic_decrement (&narenas);
+            atomic_fetch_add_relaxed (&narenas, -1);
         }
       else
--cut here--

then these lines:

+/* ??? Remove when catomic_exchange_and_add
+   fallback uses __atomic_fetch_add.  */
+#define catomic_exchange_and_add(mem, value) \
+  __atomic_fetch_add (mem, value, __ATOMIC_ACQUIRE)

should be removed from atomic-machine.h. These lines are only
temporary remedies to avoid the cmpxchg loop, as explained in detail
in the commit message.

I have attached the final x86 atomic-machine.h that can be used to
generate optimal code. After the above two mentioned changes are
committed, ??? part can be removed, and the generated code will be the
same.

Uros.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: atomic-machine.h
Type: text/x-chdr
Size: 2341 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250908/448a97ac/attachment-0001.bin>