public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "wilco at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64 Date: Fri, 02 Jun 2023 20:37:06 +0000 [thread overview] Message-ID: <bug-110061-4-MhttP09efu@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-110061-4@http.gcc.gnu.org/bugzilla/> 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"?
next prev parent reply other threads:[~2023-06-02 20:37 UTC|newest] Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-05-31 12:46 [Bug target/110061] New: " wilco at gcc dot gnu.org 2023-05-31 12:55 ` [Bug target/110061] " pinskia at gcc dot gnu.org 2023-05-31 12:59 ` pinskia at gcc dot gnu.org 2023-05-31 13:24 ` pinskia at gcc dot gnu.org 2023-05-31 13:59 ` wilco at gcc dot gnu.org 2023-05-31 14:04 ` pinskia at gcc dot gnu.org 2023-05-31 14:06 ` pinskia at gcc dot gnu.org 2023-05-31 14:36 ` wilco at gcc dot gnu.org 2023-06-02 16:02 ` xry111 at gcc dot gnu.org 2023-06-02 17:02 ` wilco at gcc dot gnu.org 2023-06-02 17:49 ` xry111 at gcc dot gnu.org 2023-06-02 20:37 ` wilco at gcc dot gnu.org [this message] 2023-06-02 20:41 ` xry111 at gcc dot gnu.org 2023-06-02 20:48 ` wilco at gcc dot gnu.org 2023-06-02 21:23 ` wilco at gcc dot gnu.org 2023-06-04 10:23 ` xry111 at gcc dot gnu.org 2023-12-22 14:38 ` wilco at gcc dot gnu.org 2024-03-18 1:02 ` raj.khem at gmail dot com 2024-03-18 1:06 ` pinskia at gcc dot gnu.org 2024-05-07 7:40 ` rguenth at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-110061-4-MhttP09efu@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).