<html>
<head>
<base href="https://bugs.llvm.org/">
</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 - Promote loop access to scalars (LICM) blocked by unrelated volatile access"
href="https://bugs.llvm.org/show_bug.cgi?id=39416">39416</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Promote loop access to scalars (LICM) blocked by unrelated volatile access
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</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>Loop Optimizer
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>bruno-llvm@defraine.net
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Consider the following example:
extern int x;
extern volatile int v;
int f(int) __attribute__((const));
void test() {
for (int i = 0; i < 100; ++i) {
x = f(x);
v = 1;
}
}
Godbolt URL: <a href="https://godbolt.org/z/yZo4lj">https://godbolt.org/z/yZo4lj</a>
I expect that LICM optimization would move the load/store of "x" outside of
this loop, but this seems blocked by the access to volatile "v".
Note that GCC does move the load/store of "x" outside of the loop.
While only a missed optimization, this is unexpected, because the optimization
is otherwise done (if you comment out the access to "v", which you would expect
to be unrelated, LICM does promote the accesses of "x" to scalars). Also, when
you unroll such a loop, LLVM can eliminate the redundant intermediate
load/store operations. Consider:
void test_unrolled() {
x = f(x);
v = 1;
x = f(x);
v = 1;
x = f(x);
v = 1;
}
Godbolt URL: <a href="https://godbolt.org/z/0Iwsno">https://godbolt.org/z/0Iwsno</a>
This has only a single load and store of "x", respectively at the beginning and
end. So the optimization in case of the loop is certainly safe (or both GCC and
LLVM outside of a loop are wrong...).</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>