[Bug target/110061] New: libatomic: 128-bit atomics should be lock-free on AArch64

[Bug target/110061] New: libatomic: 128-bit atomics should be lock-free on AArch64

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

            Bug ID: 110061
           Summary: libatomic: 128-bit atomics should be lock-free on
                    AArch64
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wilco at gcc dot gnu.org
  Target Milestone: ---

128-bit atomics should be lock-free on AArch64. This is what most users expect,
gives better performance and makes it possible to inline/outline the recently
added 128-bit atomic instructions. It also makes GCC and LLVM ABI compatible
(since LLVM atomics are always lock-free).

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
But it is not valid thing to do.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=108659

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Llvm making wrong choices does not mean gcc has to follow them.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 70814. Basically 128bit atomics CANNOT be lock free with ARMv8-a.

*** This bug has been marked as a duplicate of bug 70814 ***

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

Wilco <wilco at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-05-31
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=80878
           Assignee|unassigned at gcc dot gnu.org      |wilco at gcc dot gnu.org
             Status|RESOLVED                    |NEW
         Resolution|DUPLICATE                   |---
     Ever confirmed|0                           |1

--- Comment #4 from Wilco <wilco at gcc dot gnu.org> ---
Reopened. Please don't close bugs without allowing for discussion first. I'll
send a patch soon that shows it's possible and valid.

And if there is a better solution that results in the same benefits (fast
lock-free atomics, allowing inlining and use of latest instructions without ABI
issues) then I would love to hear ideas and suggestions.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Still a dup. Reopen the old one instead if you think gcc should be broken for
loads.

*** This bug has been marked as a duplicate of bug 70814 ***

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
bug 70814 comment #3 explains why this should not be done. As I mentioned it
can be improved for armv8.4-a maybe using an ifunc but it cannot be done for
before that.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

Wilco <wilco at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|DUPLICATE                   |---
             Status|RESOLVED                    |NEW

--- Comment #7 from Wilco <wilco at gcc dot gnu.org> ---
I don't see the issue you have here. GCC for x86/x86_64 has been using compare
exchange for atomic load (which always does a write even if the compare fails)
for many years. LLVM does the same for AArch64/x86/x86_64.

If you believe this is incorrect/invalid, do you have any evidence this causes
crashes in real applications?

As a result of GCC's bad choice of using locking atomics on AArch64, many
applications are forced to implement 128-bit atomics themselves using hacky
inline assembler. Just one example for reference:

https://github.com/boostorg/atomic/blob/08bd4e20338c503d2acfdddfdaa8f5e0bcf9006c/include/boost/atomic/detail/core_arch_ops_gcc_aarch64.hpp#L1635

The question is, do you believe compilers should provide users with fast and
efficient atomics they need? Or do you want to force every application to
implement their own version of 128-bit atomics?

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #8 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Wilco from comment #7)
> I don't see the issue you have here. GCC for x86/x86_64 has been using
> compare exchange for atomic load (which always does a write even if the
> compare fails) for many years.

No we don't, since r7-6454.

> The question is, do you believe compilers should provide users with fast and
> efficient atomics they need? Or do you want to force every application to
> implement their own version of 128-bit atomics?

But a compiler must generate correct code first.  They can use the wonderful
inline assembly because they know CAS is safe in their case, but the compiler
does not know.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

--- Comment #9 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #8)
> (In reply to Wilco from comment #7)
> > I don't see the issue you have here. GCC for x86/x86_64 has been using
> > compare exchange for atomic load (which always does a write even if the
> > compare fails) for many years.
> 
> No we don't, since r7-6454.

Incorrect - libatomic still uses cmpxchg16b depending on the CPU.

> > The question is, do you believe compilers should provide users with fast and
> > efficient atomics they need? Or do you want to force every application to
> > implement their own version of 128-bit atomics?
> 
> But a compiler must generate correct code first.  They can use the wonderful
> inline assembly because they know CAS is safe in their case, but the
> compiler does not know.

Many developers consider locking atomics fundamentally incorrect. If we emit
lock-free atomics they don't need to write inline assembler.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

--- Comment #10 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Wilco from comment #9)
> (In reply to Xi Ruoyao from comment #8)
> > (In reply to Wilco from comment #7)
> > > I don't see the issue you have here. GCC for x86/x86_64 has been using
> > > compare exchange for atomic load (which always does a write even if the
> > > compare fails) for many years.
> > 
> > No we don't, since r7-6454.
> 
> Incorrect - libatomic still uses cmpxchg16b depending on the CPU.

You are incorrect.  It checks cmpxchg16b bit in CPUID but does not use the
cmpxchg16b instruction.

The reason to check cmpxchg16b is both Intel and AMD guarantee that if both
cmpxchg16b and AVX are available, then an aligned 16-byte load with vmovdqa is
atomic.  So we can use vmovdqa to do a lock-free load then.  But using
cmpxchg16b for a load is still wrong, and libatomic do NOT use it.

> > > The question is, do you believe compilers should provide users with fast and
> > > efficient atomics they need? Or do you want to force every application to
> > > implement their own version of 128-bit atomics?
> > 
> > But a compiler must generate correct code first.  They can use the wonderful
> > inline assembly because they know CAS is safe in their case, but the
> > compiler does not know.
> 
> Many developers consider locking atomics fundamentally incorrect. If we emit
> lock-free atomics they don't need to write inline assembler.

Then the compiler (and the standard) is not what they consider.  Such
misunderstandings are everywhere and this has no difference.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

--- Comment #11 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #10)
> (In reply to Wilco from comment #9)
> > (In reply to Xi Ruoyao from comment #8)
> > > (In reply to Wilco from comment #7)
> > > > I don't see the issue you have here. GCC for x86/x86_64 has been using
> > > > compare exchange for atomic load (which always does a write even if the
> > > > compare fails) for many years.
> > > 
> > > No we don't, since r7-6454.
> > 
> > Incorrect - libatomic still uses cmpxchg16b depending on the CPU.
> 
> You are incorrect.  It checks cmpxchg16b bit in CPUID but does not use the
> cmpxchg16b instruction.

No, it will use the cmpxchg16b instruction in the other ifunc when AVX is not
available. Libatomic will fallback to locking atomics if neither AVX nor
cmpxchg16b are available (first few generations of x86_64).

> The reason to check cmpxchg16b is both Intel and AMD guarantee that if both
> cmpxchg16b and AVX are available, then an aligned 16-byte load with vmovdqa
> is atomic.  So we can use vmovdqa to do a lock-free load then.  But using
> cmpxchg16b for a load is still wrong, and libatomic do NOT use it.
> 
> > > > The question is, do you believe compilers should provide users with fast and
> > > > efficient atomics they need? Or do you want to force every application to
> > > > implement their own version of 128-bit atomics?
> > > 
> > > But a compiler must generate correct code first.  They can use the wonderful
> > > inline assembly because they know CAS is safe in their case, but the
> > > compiler does not know.
> > 
> > Many developers consider locking atomics fundamentally incorrect. If we emit
> > lock-free atomics they don't need to write inline assembler.
> 
> Then the compiler (and the standard) is not what they consider.  Such
> misunderstandings are everywhere and this has no difference.

Where is int128 in "the standard"?

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

--- Comment #12 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Wilco from comment #11)

> > Then the compiler (and the standard) is not what they consider.  Such
> > misunderstandings are everywhere and this has no difference.
> 
> Where is int128 in "the standard"?

Consider this:

const _Atomic long double x = 0.1;

int main()
{
        double y = x;
        return y != 0.1;
}

If CAS is used here, the program will just segfault.  Does the standard say
this is ill-formed or not?

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

--- Comment #13 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Xi Ruoyao from comment #12)
> (In reply to Wilco from comment #11)
> 
> > > Then the compiler (and the standard) is not what they consider.  Such
> > > misunderstandings are everywhere and this has no difference.
> > 
> > Where is int128 in "the standard"?
> 
> Consider this:
> 
> const _Atomic long double x = 0.1;
> 
> int main()
> {
> 	double y = x;
> 	return y != 0.1;
> }
> 
> If CAS is used here, the program will just segfault.  Does the standard say
> this is ill-formed or not?

I'd say this is ill formed yes. And it will crash on Atom laptops.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

--- Comment #14 from Wilco <wilco at gcc dot gnu.org> ---
(In reply to Wilco from comment #13)
> (In reply to Xi Ruoyao from comment #12)
> > (In reply to Wilco from comment #11)
> > 
> > > > Then the compiler (and the standard) is not what they consider.  Such
> > > > misunderstandings are everywhere and this has no difference.
> > > 
> > > Where is int128 in "the standard"?
> > 
> > Consider this:
> > 
> > const _Atomic long double x = 0.1;
> > 
> > int main()
> > {
> > 	double y = x;
> > 	return y != 0.1;
> > }
> > 
> > If CAS is used here, the program will just segfault.  Does the standard say
> > this is ill-formed or not?
> 
> I'd say this is ill formed yes. And it will crash on Atom laptops.

Correction - it crashes on all AMD cpus too. Are you going to file bugreports
for this?

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

--- Comment #15 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Wilco from comment #14)
> (In reply to Wilco from comment #13)
> > (In reply to Xi Ruoyao from comment #12)
> > > (In reply to Wilco from comment #11)
> > > 
> > > > > Then the compiler (and the standard) is not what they consider.  Such
> > > > > misunderstandings are everywhere and this has no difference.
> > > > 
> > > > Where is int128 in "the standard"?
> > > 
> > > Consider this:
> > > 
> > > const _Atomic long double x = 0.1;
> > > 
> > > int main()
> > > {
> > > 	double y = x;
> > > 	return y != 0.1;
> > > }
> > > 
> > > If CAS is used here, the program will just segfault.  Does the standard say
> > > this is ill-formed or not?
> > 
> > I'd say this is ill formed yes. And it will crash on Atom laptops.
> 
> Correction - it crashes on all AMD cpus too. Are you going to file
> bugreports for this?

PR95722.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[wilco at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

Wilco <wilco at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

--- Comment #16 from Wilco <wilco at gcc dot gnu.org> ---
Fixed by
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3fa689f6ed8387d315e58169bb9bace3bd508c0a

libatomic: Enable lock-free 128-bit atomics on AArch64

Enable lock-free 128-bit atomics on AArch64.  This is backwards compatible with
existing binaries (as for these GCC always calls into libatomic, so all 128-bit
atomic uses in a process are switched), gives better performance than locking
atomics and is what most users expect.

128-bit atomic loads use a load/store exclusive loop if LSE2 is not supported.
This results in an implicit store which is invisible to software as long as the
given address is writeable (which will be true when using atomics in real
code).

This doesn't yet change __atomic_is_lock_free eventhough all atomics are
finally
lock-free on AArch64.

libatomic:
        * config/linux/aarch64/atomic_16.S: Implement lock-free ARMv8.0
atomics.
        (libat_exchange_16): Merge RELEASE and ACQ_REL/SEQ_CST cases.
        * config/linux/aarch64/host-config.h: Use atomic_16.S for baseline
v8.0.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[raj.khem at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

Khem Raj <raj.khem at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |raj.khem at gmail dot com

--- Comment #17 from Khem Raj <raj.khem at gmail dot com> ---
@wilco this commit is now regressing builds for musl/aarch64, where libatomic
fails to compile. With errors like

In file included from /home/kraj/work/gcc/libatomic/exch_n.c:25:
/home/kraj/work/gcc/libatomic/libatomic_i.h:288:40: error: ‘export_exchange_16’
aliased to undefined symbol ‘libat_exchange_16’
  288 |         extern typeof(C2(libat_,X)) C2(export_,X)               \
      |                                        ^~~~~~~
/home/kraj/work/gcc/libatomic/libatomic_i.h:40:25: note: in definition of macro
‘C2_’
   40 | #define C2_(X,Y)        X ## Y
      |                         ^
/home/kraj/work/gcc/libatomic/libatomic_i.h:288:37: note: in expansion of macro
‘C2’
  288 |         extern typeof(C2(libat_,X)) C2(export_,X)               \
      |                                     ^~
/home/kraj/work/gcc/libatomic/exch_n.c:128:1: note: in expansion of macro
‘EXPORT_ALIAS’
  128 | EXPORT_ALIAS (SIZE(exchange));
      | ^~~~~~~~~~~~
In file included from /home/kraj/work/gcc/libatomic/fop_n.c:25,
                 from /home/kraj/work/gcc/libatomic/fand_n.c:3:
/home/kraj/work/gcc/libatomic/libatomic_i.h:288:40: error:
‘export_fetch_and_16’ aliased to undefined symbol ‘libat_fetch_and_16’
  288 |         extern typeof(C2(libat_,X)) C2(export_,X)               \
      |                                        ^~~~~~~
/home/kraj/work/gcc/libatomic/libatomic_i.h:40:25: note: in definition of macro
‘C2_’
   40 | #define C2_(X,Y)        X ## Y
      |                         ^
/home/kraj/work/gcc/libatomic/libatomic_i.h:288:37: note: in expansion of macro
‘C2’
  288 |         extern typeof(C2(libat_,X)) C2(export_,X)               \
      |                                     ^~
/home/kraj/work/gcc/libatomic/fop_n.c:199:1: note: in expansion of macro
‘EXPORT_ALIAS’
  199 | EXPORT_ALIAS (SIZE(C2(fetch_,NAME)));
      | ^~~~~~~~~~~~
In file included from /home/kraj/work/gcc/libatomic/fadd_n.c:25:
/home/kraj/work/gcc/libatomic/libatomic_i.h:288:40: error:
‘export_fetch_add_16’ aliased to undefined symbol ‘libat_fetch_add_16’
  288 |         extern typeof(C2(libat_,X)) C2(export_,X)               \
      |                                        ^~~~~~~

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=113986

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Khem Raj from comment #17)
> @wilco this commit is now regressing builds for musl/aarch64, where
> libatomic fails to compile. With errors like

Yes and already known is recorded as PR 113986 .

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110061

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|14.0                        |14.2

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 14.1 is being released, retargeting bugs to GCC 14.2.