public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/66881] New: Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic
@ 2015-07-15 16:05 tkoeppe at google dot com
2015-07-15 16:23 ` [Bug middle-end/66881] " hjl.tools at gmail dot com
` (5 more replies)
0 siblings, 6 replies; 7+ messages in thread
From: tkoeppe at google dot com @ 2015-07-15 16:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881
Bug ID: 66881
Summary: Possibly inefficient std::atomic<int> codegen on x86
for simple arithmetic
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoeppe at google dot com
Target Milestone: ---
Consider these two simple versions of addition:
#include <atomic>
std::atomic<int> x;
int y;
void f(int a) {
x.store(x.load(std::memory_order_relaxed) + a, std::memory_order_relaxed);
}
void g(int a) {
y += a;
}
GCC generates the following assembly:
f(int):
mov eax, DWORD PTR x[rip]
add edi, eax
mov DWORD PTR x[rip], edi
ret
g(int):
add DWORD PTR y[rip], edi
ret
Now, it is clear to me that the correct atomic codegen for store() and load()
is "mov", as it appears here, but why aren't the two consecutive operations not
folded into a single add? Aren't the semantics and the memory ordering the
same? x86 says that (most) "reads" and "writes" are strongly ordered; doesn't
that apply to the read and write produced by "add", too?
(My original motivation came from a variant of this with floats, where the
non-atomic code executed noticeably faster, even though I would have expected
the two to produce the same machine code.)
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/66881] Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic
2015-07-15 16:05 [Bug middle-end/66881] New: Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic tkoeppe at google dot com
@ 2015-07-15 16:23 ` hjl.tools at gmail dot com
2015-07-15 16:29 ` ville.voutilainen at gmail dot com
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: hjl.tools at gmail dot com @ 2015-07-15 16:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881
--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
Dup of PR 50677?
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/66881] Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic
2015-07-15 16:05 [Bug middle-end/66881] New: Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic tkoeppe at google dot com
2015-07-15 16:23 ` [Bug middle-end/66881] " hjl.tools at gmail dot com
@ 2015-07-15 16:29 ` ville.voutilainen at gmail dot com
2015-07-15 16:30 ` hjl.tools at gmail dot com
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: ville.voutilainen at gmail dot com @ 2015-07-15 16:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881
--- Comment #2 from Ville Voutilainen <ville.voutilainen at gmail dot com> ---
(In reply to H.J. Lu from comment #1)
> Dup of PR 50677?
Well, this report has no volatiles in it, so perhaps not?
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/66881] Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic
2015-07-15 16:05 [Bug middle-end/66881] New: Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic tkoeppe at google dot com
2015-07-15 16:23 ` [Bug middle-end/66881] " hjl.tools at gmail dot com
2015-07-15 16:29 ` ville.voutilainen at gmail dot com
@ 2015-07-15 16:30 ` hjl.tools at gmail dot com
2015-07-15 16:37 ` hjl.tools at gmail dot com
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: hjl.tools at gmail dot com @ 2015-07-15 16:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881
--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Ville Voutilainen from comment #2)
> (In reply to H.J. Lu from comment #1)
> > Dup of PR 50677?
>
> Well, this report has no volatiles in it, so perhaps not?
Can you change init_recog_no_volatile to try it out?
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/66881] Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic
2015-07-15 16:05 [Bug middle-end/66881] New: Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic tkoeppe at google dot com
` (2 preceding siblings ...)
2015-07-15 16:30 ` hjl.tools at gmail dot com
@ 2015-07-15 16:37 ` hjl.tools at gmail dot com
2015-07-15 16:37 ` hjl.tools at gmail dot com
2015-07-20 21:57 ` jfb at chromium dot org
5 siblings, 0 replies; 7+ messages in thread
From: hjl.tools at gmail dot com @ 2015-07-15 16:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |DUPLICATE
--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
*** This bug has been marked as a duplicate of bug 50677 ***
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/66881] Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic
2015-07-15 16:05 [Bug middle-end/66881] New: Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic tkoeppe at google dot com
` (3 preceding siblings ...)
2015-07-15 16:37 ` hjl.tools at gmail dot com
@ 2015-07-15 16:37 ` hjl.tools at gmail dot com
2015-07-20 21:57 ` jfb at chromium dot org
5 siblings, 0 replies; 7+ messages in thread
From: hjl.tools at gmail dot com @ 2015-07-15 16:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
Dup.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug middle-end/66881] Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic
2015-07-15 16:05 [Bug middle-end/66881] New: Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic tkoeppe at google dot com
` (4 preceding siblings ...)
2015-07-15 16:37 ` hjl.tools at gmail dot com
@ 2015-07-20 21:57 ` jfb at chromium dot org
5 siblings, 0 replies; 7+ messages in thread
From: jfb at chromium dot org @ 2015-07-20 21:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881
JF Bastien <jfb at chromium dot org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jfb at chromium dot org
--- Comment #6 from JF Bastien <jfb at chromium dot org> ---
I don't think this is a duplicate of PR 50677: this issue uses two *separate*
atomic operations, which inherently aren't atomic, whereas PR 50677 uses a
single volatile operations which some (misguided) developers expect to be
atomic.
The compiler may decide to be nice to developers who have misguided
expectations from using volatile, but this example clearly uses separate
load/store operations. I believe Thomas is correct: the code for f() should
codegen the same code as g().
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-07-20 21:57 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-15 16:05 [Bug middle-end/66881] New: Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic tkoeppe at google dot com
2015-07-15 16:23 ` [Bug middle-end/66881] " hjl.tools at gmail dot com
2015-07-15 16:29 ` ville.voutilainen at gmail dot com
2015-07-15 16:30 ` hjl.tools at gmail dot com
2015-07-15 16:37 ` hjl.tools at gmail dot com
2015-07-15 16:37 ` hjl.tools at gmail dot com
2015-07-20 21:57 ` jfb at chromium dot org
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).