https://bugs.llvm.org/show_bug.cgi?id=39416
Bug ID: 39416
Summary: Promote loop access to scalars (LICM) blocked by
unrelated volatile access
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Loop Optimizer
Assignee: unassignedb...@nondot.org
Reporter: bruno-l...@defraine.net
CC: llvm-bugs@lists.llvm.org
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: https://godbolt.org/z/yZo4lj
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: https://godbolt.org/z/0Iwsno
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...).
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
