public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel CPUs with AVX Date: Tue, 29 Mar 2022 05:54:14 +0000 [thread overview] Message-ID: <bug-104688-4-hFPi1fDKKm@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-104688-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 --- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-11 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:1861b9a9f13c64333306a2eb146b2da0a41d044f commit r11-9729-g1861b9a9f13c64333306a2eb146b2da0a41d044f Author: Jakub Jelinek <jakub@redhat.com> Date: Thu Mar 17 18:49:00 2022 +0100 libatomic: Improve 16-byte atomics on Intel AVX [PR104688] As mentioned in the PR, the latest Intel SDM has added: "Processors that enumerate support for Intel® AVX (by setting the feature flag CPUID.01H:ECX.AVX[bit 28]) guarantee that the 16-byte memory operations performed by the following instructions will always be carried out atomically: ⢠MOVAPD, MOVAPS, and MOVDQA. ⢠VMOVAPD, VMOVAPS, and VMOVDQA when encoded with VEX.128. ⢠VMOVAPD, VMOVAPS, VMOVDQA32, and VMOVDQA64 when encoded with EVEX.128 and k0 (masking disabled). (Note that these instructions require the linear addresses of their memory operands to be 16-byte aligned.)" The following patch deals with it just on the libatomic library side so far, currently (since ~ 2017) we emit all the __atomic_* 16-byte builtins as library calls since and this is something that we can hopefully backport. The patch simply introduces yet another ifunc variant that takes priority over the pure CMPXCHG16B one, one that checks AVX and CMPXCHG16B bits and on non-Intel clears the AVX bit during detection for now (if AMD comes with the same guarantee, we could revert the config/x86/init.c hunk), which implements 16-byte atomic load as vmovdqa and 16-byte atomic store as vmovdqa followed by mfence. 2022-03-17 Jakub Jelinek <jakub@redhat.com> PR target/104688 * Makefile.am (IFUNC_OPTIONS): Change on x86_64 to -mcx16 -mcx16. (libatomic_la_LIBADD): Add $(addsuffix _16_2_.lo,$(SIZEOBJS)) for x86_64. * Makefile.in: Regenerated. * config/x86/host-config.h (IFUNC_COND_1): For x86_64 define to both AVX and CMPXCHG16B bits. (IFUNC_COND_2): Define. (IFUNC_NCOND): For x86_64 define to 2 * (N == 16). (MAYBE_HAVE_ATOMIC_CAS_16, MAYBE_HAVE_ATOMIC_EXCHANGE_16, MAYBE_HAVE_ATOMIC_LDST_16): Define to IFUNC_COND_2 rather than IFUNC_COND_1. (HAVE_ATOMIC_CAS_16): Redefine to 1 whenever IFUNC_ALT != 0. (HAVE_ATOMIC_LDST_16): Redefine to 1 whenever IFUNC_ALT == 1. (atomic_compare_exchange_n): Define whenever IFUNC_ALT != 0 on x86_64 for N == 16. (__atomic_load_n, __atomic_store_n): Redefine whenever IFUNC_ALT == 1 on x86_64 for N == 16. (atomic_load_n, atomic_store_n): New functions. * config/x86/init.c (__libat_feat1_init): On x86_64 clear bit_AVX if CPU vendor is not Intel. (cherry picked from commit 1d47c0512a265d4bb3ab9e56259fd1e4f4d42c75)
next prev parent reply other threads:[~2022-03-29 5:54 UTC|newest] Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-25 14:22 [Bug target/104688] New: " xry111 at mengyan1223 dot wang 2022-02-25 14:30 ` [Bug target/104688] " jakub at gcc dot gnu.org 2022-02-25 14:33 ` xry111 at mengyan1223 dot wang 2022-02-25 14:34 ` fw at gcc dot gnu.org 2022-02-25 16:36 ` jakub at gcc dot gnu.org 2022-02-25 16:37 ` jakub at gcc dot gnu.org 2022-03-17 17:50 ` cvs-commit at gcc dot gnu.org 2022-03-29 5:54 ` cvs-commit at gcc dot gnu.org [this message] 2022-04-05 12:30 ` xry111 at mengyan1223 dot wang 2022-04-05 12:35 ` jakub at gcc dot gnu.org 2022-11-14 3:31 ` Ganesh.Gopalasubramanian at amd dot com 2022-11-14 4:58 ` sam at gentoo dot org 2022-11-14 5:10 ` [Bug target/104688] gcc and libatomic can use SSE for 128-bit atomic loads on Intel and AMD " xry111 at gcc dot gnu.org 2022-11-14 7:54 ` jakub at gcc dot gnu.org 2022-11-14 9:24 ` amonakov at gcc dot gnu.org 2022-11-14 9:29 ` jakub at gcc dot gnu.org 2022-11-14 9:52 ` amonakov at gcc dot gnu.org 2022-11-15 7:18 ` cvs-commit at gcc dot gnu.org 2022-11-15 7:20 ` jakub at gcc dot gnu.org 2022-11-20 23:11 ` cvs-commit at gcc dot gnu.org 2022-11-21 9:23 ` cvs-commit at gcc dot gnu.org 2022-11-23 9:18 ` xry111 at gcc dot gnu.org 2022-11-23 9:51 ` jakub at gcc dot gnu.org 2022-11-23 10:23 ` xry111 at gcc dot gnu.org 2022-11-28 18:35 ` peter at cordes dot ca 2022-11-28 18:46 ` amonakov at gcc dot gnu.org 2022-11-28 19:03 ` peter at cordes dot ca 2022-11-28 20:11 ` amonakov at gcc dot gnu.org 2022-11-28 20:47 ` peter at cordes dot ca 2022-11-29 8:11 ` fw at gcc dot gnu.org 2023-02-15 12:27 ` segher at gcc dot gnu.org 2023-02-15 12:46 ` fw at gcc dot gnu.org 2023-02-15 16:03 ` segher at gcc dot gnu.org 2023-02-15 16:07 ` pinskia at gcc dot gnu.org 2023-02-15 16:09 ` segher 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-104688-4-hFPi1fDKKm@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).