[llvm-bugs] [Bug 51980] New: miscompile with opt -passes='function(loop-flatten)'

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=51980

            Bug ID: 51980
           Summary: miscompile with opt -passes='function(loop-flatten)'
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: mikael.holmen at ericsson.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 25296
  --> https://bugs.llvm.org/attachment.cgi?id=25296&action=edit
bbi-60764.ll reproducer

llvm commit: 902ec6142a6f6

Reproduce with
 opt -passes='function(loop-flatten)' -S -o - bbi-60764.ll

The input has two nested loops, the outer for i [0, 3] and the inner for j [0,
15] and loop-flatten flattens it to one loop iterating for i' in [0, 63] which
looks ok.

In the inner loop there is a load from v[16*i+j] but after flattening as far as
I can see it loads from v[16*i'] so it quickly goes out-of-bounds of v and read
random data instead.

So in the result there is

entry:
  %flatten.tripcount = mul i32 16, 4
  br label %for.cond1.preheader

for.cond1.preheader:                              ; preds = %for.cond.cleanup3,
%entry
  %indvar2 = phi i32 [ %indvar.next3, %for.cond.cleanup3 ], [ 0, %entry ]
  %i.013 = phi i16 [ 0, %entry ], [ %inc7, %for.cond.cleanup3 ]
  %sum.012 = phi i16 [ 0, %entry ], [ %add5.lcssa, %for.cond.cleanup3 ]
  %0 = mul nsw i32 %indvar2, 16

[...]
for.body4:                                        ; preds =
%for.cond1.preheader
  %indvar = phi i32 [ 0, %for.cond1.preheader ]
  %2 = add nuw nsw i32 %indvar, %0
  %3 = trunc i32 %2 to i16
  %arrayidx = getelementptr inbounds [64 x i16], [64 x i16]* @v, i16 0, i16 %3
  %4 = load i16, i16* %arrayidx, align 1

This starts happening with 6a076fa9539:

    [LoopFlatten] Make the analysis more robust after IV widening

    LoopFlatten wasn't triggering on this motivating case after IV widening:

      void foo(int *A, int N, int M) {
        for (int i = 0; i < N; ++i)
          for (int j = 0; j < M; ++j)
            f(A[i*M+j]);
      }

    The reason was that the old induction phi nodes were getting in the way.
These
    narrow and dead induction phis are not always trivially dead, and having
both
    the narrow and wide IVs confused the analysis and caused it to bail. This
adds
    some extra bookkeeping for these old phis, so we can filter them out when
    checks on phi nodes are performed. Other clean up passes will get rid of
these
    old phis and increment instructions.

    As this was one of the motivating examples from the beginning, it was
    surprising this wasn't triggering from C/C++ code. It looks like the IR and
CFG
    is just slightly different.

    Differential Revision: https://reviews.llvm.org/D109309


Note that before this patch, the above reproducer hit an error about a broken
PHI, so there was certainly something strange going on then too.

-- 
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/20210927/dfd66788/attachment-0001.html>