[PATCH] D109309: [LoopFlatten] Make the analysis more robust after IV widening

[Mikael Holmén via Phabricator via llvm-commits]

uabelho added a comment.

Hi,

I've hunted down a miscompile that seems to start happening with this commit.
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

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.
F19274808: bbi-60764.ll <https://reviews.llvm.org/F19274808>


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D109309/new/

https://reviews.llvm.org/D109309