[llvm-bugs] [Bug 32314] New: Miscompile in GVN due to bug in BasisAA

[via llvm-bugs]

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

            Bug ID: 32314
           Summary: Miscompile in GVN due to bug in BasisAA
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: craig.topper at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 18113
  --> http://bugs.llvm.org/attachment.cgi?id=18113&action=edit
IR just before GVN runs.

In the attached IR, GVN removes the following load

  %6 = load i32, i32* %p.017, align 4, !tbaa !1

as it believes it can get the value from the previous iteration of the loop.

What it fails to realize is that this store

  store i32 50, i32* %arrayidx, align 4, !tbaa !1

aliases the load.

This is because during BasicAA we go through this PHI feeding the load

  %p.017 = phi i32* [ %r, %entry ], [ %arrayidx3, %for.body ]

to find this GEP

  %arrayidx3 = getelementptr inbounds [3 x i32], [3 x i32]* %a, i64 0, i64
%indvars.iv

then compare it to this GEP which feeds the store

  %arrayidx = getelementptr inbounds [3 x i32], [3 x i32]* %a, i64 0, i64 %4

Then we ask ValueTracking if %4 is known non-equal to %indvars.iv.
ValueTracking sees that %4 is equal to %indvars.iv - 1, so returns that they
are known non-equal and BasicAA returns NoAlias. But this is wrong because we
crossed a PHI to get to the GEP using %indvars.i so we're really looking at
%indvars.iv from two different loop iterations.

-- 
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/20170316/91edff8a/attachment.html>