[LLVMbugs] [Bug 18848] New: gvn does not remove loads after loop

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=18848

            Bug ID: 18848
           Summary: gvn does not remove loads after loop
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: tobias at grosser.es
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 12064
  --> http://llvm.org/bugs/attachment.cgi?id=12064&action=edit
The LLVM-IR file to reproduce this bug

When computing the following C code:

void f(float *restrict A, float *restrict B, long N) {
  B[0] = A[0];
  for (long i = 1; i < N - 1; i += 1) {
    B[i - 1] += A[i];
    B[i] = A[i];  // Last iteration:  B[N-2] = A[N-2];
  }
  B[N - 2] += A[N - 1];
}

global value numbering successfully eliminates redundant loads from B within
the loop body, but it does not eliminate the redundant load of B right after
the loop body.

The attached test case was slightly simplified to ensure the loop body
dominates the statement after it.

When running the following command 'opt -basicaa store.preopt.ll -gvn
-scalar-evolution -analyze' we get the following information:

Index of store in the loop body:

  %arrayidx6 = getelementptr inbounds float* %B, i64 %storemerge9
  -->  {(4 + %B),+,4}<nsw><%for.body>        Exits: (-8 + (4 * %N) + %B)

Index of load after the loop:
  %arrayidx11 = getelementptr inbounds float* %B, i64 %sub10
  -->  (-8 + (4 * %N) + %B)

Both registers have the same value after the loop. We should eliminate both the
load that comes right after the store as well as the unnecessary index
computation.

-- 
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/20140215/f21dd251/attachment.html>