public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/94649] New: 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
@ 2020-04-18 18:17 avi@cloudius-systems.com
2020-04-20 7:03 ` [Bug target/94649] " rguenth at gcc dot gnu.org
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: avi@cloudius-systems.com @ 2020-04-18 18:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
Bug ID: 94649
Summary: 16-byte aligned atomic_compare_exchange doesn not
generate cmpxcg16b on x86_64
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: avi@cloudius-systems.com
Target Milestone: ---
The code
#include <atomic>
struct alignas(16) a {
long x;
long y;
};
bool cmpxchg(std::atomic<a>& data, a expected, a newval) {
return std::atomic_compare_exchange_weak(&data, &expected, newval);
}
compiles with -O3 -mcx16 generates a "lock cmpxchg16b" instruction with clang,
but not with gcc, where it generates a library call to
__atomic_compare_exchange_16. This is a missed optimization.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
2020-04-18 18:17 [Bug c++/94649] New: 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64 avi@cloudius-systems.com
@ 2020-04-20 7:03 ` rguenth at gcc dot gnu.org
2020-04-20 11:37 ` avi@cloudius-systems.com
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-04-20 7:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |x86_64-*-*
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's also an ABI issue when code compiled with -mcx16 and without -mcx16 has to
inter-operate. So it might be a deliberate choice and not a missed
optimization.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
2020-04-18 18:17 [Bug c++/94649] New: 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64 avi@cloudius-systems.com
2020-04-20 7:03 ` [Bug target/94649] " rguenth at gcc dot gnu.org
@ 2020-04-20 11:37 ` avi@cloudius-systems.com
2021-03-14 3:10 ` wuyongwei at gmail dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: avi@cloudius-systems.com @ 2020-04-20 11:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
--- Comment #2 from Avi Kivity <avi@cloudius-systems.com> ---
Maybe we can have a new flag -mcx16all that assumes that all code using 16-byte
CAS is compiled with the flag.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
2020-04-18 18:17 [Bug c++/94649] New: 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64 avi@cloudius-systems.com
2020-04-20 7:03 ` [Bug target/94649] " rguenth at gcc dot gnu.org
2020-04-20 11:37 ` avi@cloudius-systems.com
@ 2021-03-14 3:10 ` wuyongwei at gmail dot com
2021-05-07 14:44 ` s_gccbugzilla at nedprod dot com
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: wuyongwei at gmail dot com @ 2021-03-14 3:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
Yongwei Wu <wuyongwei at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wuyongwei at gmail dot com
--- Comment #3 from Yongwei Wu <wuyongwei at gmail dot com> ---
Is there really a valid use case for a non-lock-free version of 128-bit CAS?
I am using it in a lock-free data structure. The GCC-generated code is MUCH
slower than the mutex-based version, defeating all its valid purposes. I am
talking about a 10x difference. And the Clang-generated code is more than 200x
faster in my 8-thread contention test.
To me, the current GCC behaviour is not missed optimization. It is
pessimization. I am really having a difficult time understanding the rationale
of the current design.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
2020-04-18 18:17 [Bug c++/94649] New: 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64 avi@cloudius-systems.com
` (2 preceding siblings ...)
2021-03-14 3:10 ` wuyongwei at gmail dot com
@ 2021-05-07 14:44 ` s_gccbugzilla at nedprod dot com
2023-02-15 10:56 ` balder at yahooinc dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: s_gccbugzilla at nedprod dot com @ 2021-05-07 14:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
Niall Douglas <s_gccbugzilla at nedprod dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |s_gccbugzilla at nedprod dot com
--- Comment #4 from Niall Douglas <s_gccbugzilla at nedprod dot com> ---
Relocating my issue from PR 80878 to here:
I got bit by this GCC regression today at work. Consider
https://godbolt.org/z/M9fd7nhdh where
std::atomic<__int128>::compare_exchange_weak() is called with option
-march=sandybridge passed to the command line:
- On GCC 6.4 and earlier, this emits lock cmpxchg16b, as you would expect.
- From GCC 7 up to trunk (12?), this emits __atomic_compare_exchange_16.
- On clang, this emits lock cmpxchg16b, as you would expect.
This is clearly a regression. GCCs before 7 did the right thing. GCCs from 7
onwards do not. clangs with libstdc++ do do the right thing.
Please mark this bug as a regression affecting all versions of GCC from 7 to
trunk.
--- cut ---
NOTE that unlike the original PR above where the struct is a UDT, I am talking
here about std::atomic<__int128>::compare_exchange_weak(). It seems weird that
__int128 is treated as a UDT when the CPU is perfectly capable of hardware CAS.
Common feedback from this and other PRs:
1. Changing this would break ABI
Firstly, I told GCC -march=sandybridge, and we know that libatomic will choose
cmpxchg16b to implement __atomic_compare_exchange_16 because cpuid for
sandybridge will say cmpxchg16b is supported. So, it's the same implementation
for __atomic_compare_exchange_16, nothing breaks here.
2. static const std::atomic<__int128>::load() will segfault
std::atomic<__int128> could examine the macro environment
(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 et al) and if only 128 bit compare and
swap is available, but 128 bit atomics are not, then std::atomic<__int128>
could be conditionally marked with attribute section to prevent it being stored
into the read only code section.
That said, I don't actually consider static const std::atomic<__int128>::load()
segfaulting important enough to special case, in my opinion.
3. This was changed in GCC 7 because _Atomic is broken
_Atomic is indeed broken, but I am talking about std::atomic the C++ library
type here. As Mr. Wakely said in another PR:
> std::atomic just calls the relevant __atomic built-in for all operations.
> What the built-in does is not up to libstdc++.
... to this I would say both yes and no. __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16
is not defined if the architecture relies on software emulation (libatomic) to
implement 128 bit CAS. So std::atomic<types sizeof(16)>::compare_exchange_X()
*could* examine macros for architecture and presence of
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 and inline some assembler for certain
architectures as a QoI measure, which is not ABI breaking because if
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 is 1, then libatomic will be choosing that
same assembler in any case. Note that I refer to the CAS operation only, for
load and store it's trivial to write CAS based emulations, but you could just
leave those continue to call libatomic.
Ultimately I probably agree that because _Atomic is broken, the compiler is not
the right thing to change here. But libstdc++'s std::atomic implementation is
another matter.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
2020-04-18 18:17 [Bug c++/94649] New: 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64 avi@cloudius-systems.com
` (3 preceding siblings ...)
2021-05-07 14:44 ` s_gccbugzilla at nedprod dot com
@ 2023-02-15 10:56 ` balder at yahooinc dot com
2023-02-15 10:59 ` jakub at gcc dot gnu.org
2023-02-17 7:53 ` balder at yahooinc dot com
6 siblings, 0 replies; 8+ messages in thread
From: balder at yahooinc dot com @ 2023-02-15 10:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
--- Comment #5 from Henning Baldersheim <balder at yahooinc dot com> ---
Are there any next steps here.
This is still an issue at least with gcc-12. It would be nice to get rid of the
hacks we have to avoid it.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
2020-04-18 18:17 [Bug c++/94649] New: 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64 avi@cloudius-systems.com
` (4 preceding siblings ...)
2023-02-15 10:56 ` balder at yahooinc dot com
@ 2023-02-15 10:59 ` jakub at gcc dot gnu.org
2023-02-17 7:53 ` balder at yahooinc dot com
6 siblings, 0 replies; 8+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-02-15 10:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
See PR104688
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
2020-04-18 18:17 [Bug c++/94649] New: 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64 avi@cloudius-systems.com
` (5 preceding siblings ...)
2023-02-15 10:59 ` jakub at gcc dot gnu.org
@ 2023-02-17 7:53 ` balder at yahooinc dot com
6 siblings, 0 replies; 8+ messages in thread
From: balder at yahooinc dot com @ 2023-02-17 7:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
--- Comment #7 from Henning Baldersheim <balder at yahooinc dot com> ---
Thanks, perhaps add 104688 to the see also list.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-02-17 7:53 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-18 18:17 [Bug c++/94649] New: 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64 avi@cloudius-systems.com
2020-04-20 7:03 ` [Bug target/94649] " rguenth at gcc dot gnu.org
2020-04-20 11:37 ` avi@cloudius-systems.com
2021-03-14 3:10 ` wuyongwei at gmail dot com
2021-05-07 14:44 ` s_gccbugzilla at nedprod dot com
2023-02-15 10:56 ` balder at yahooinc dot com
2023-02-15 10:59 ` jakub at gcc dot gnu.org
2023-02-17 7:53 ` balder at yahooinc dot com
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).