brunodefraine
commented
6 years ago Without pointing any blame, from an analysis of the LICM code, the relevant parts in the code base seem to be:
-
llvm::promoteLoopAccessToScalars, which decides from LoopSafetyInfo->MayThrow and LoopSafetyInfo->HeaderMayThrow to not do the optimization
-
llvm::computeLoopSafetyInfo, which decides from isGuaranteedToTransferExecutionToSuccessor to fill in MayThrow and HeaderMayThrow
-
llvm::isGuaranteedToTransferExecutionToSuccessor, which decides to return false for any volatile access
Extended Description
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...).