<html>
<head>
<base href="https://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW " title="NEW --- - Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic" href="https://urldefense.proofpoint.com/v2/url?u=https-3A__llvm.org_bugs_show-5Fbug.cgi-3Fid-3D24191&d=AwMBaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=pF93YEPyB-J_PERP4DUZOJDzFVX5ZQ57vQk33wu0vio&m=kXQF1VK7oDMAbvoHUJGPF8viM1kiRxc6EiLmQYt-86Y&s=ioldv9vhByMKfHyBnoB30sOU0bzSEaXu_LhMGgR2lvk&e=">24191</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Possibly inefficient std::atomic<int> codegen on x86 for simple arithmetic
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>3.7
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>LLVM Codegen
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>tkoeppe@google.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvmbugs@cs.uiuc.edu
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>[I also reported this issue to GCC:
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__gcc.gnu.org_bugzilla_show-5Fbug.cgi-3Fid-3D66881&d=AwMBaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=pF93YEPyB-J_PERP4DUZOJDzFVX5ZQ57vQk33wu0vio&m=kXQF1VK7oDMAbvoHUJGPF8viM1kiRxc6EiLmQYt-86Y&s=P1HKXhfxDY5ML5ceq5cmKV7sN4MdpYJ51r1uH8dShDM&e=">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66881</a>]
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;
}
Clang generates the following assembly (<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__goo.gl_IWtwkr&d=AwMBaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=pF93YEPyB-J_PERP4DUZOJDzFVX5ZQ57vQk33wu0vio&m=kXQF1VK7oDMAbvoHUJGPF8viM1kiRxc6EiLmQYt-86Y&s=RstSwd23nFh32QIv4KD-aNuFPJk1DTR4YYLrGrXsSfw&e=">https://goo.gl/IWtwkr</a>):
f(int): # @f(int)
mov eax, dword ptr [rip + x]
add eax, edi
mov dword ptr [rip + x], eax
ret
g(int): # @g(int)
add dword ptr [rip + y], 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.)</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>