[llvm-bugs] [Bug 39416] New: Promote loop access to scalars (LICM) blocked by unrelated volatile access

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: bruno-llvm at defraine.net
                CC: llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20181024/8ce316c3/attachment.html>