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

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Mar 16 09:31:03 PDT 2017


            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

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>

More information about the llvm-bugs mailing list