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

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sat Feb 15 05:20:58 PST 2014


            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

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>

More information about the llvm-bugs mailing list