[llvm-bugs] [Bug 42969] New: LICM miscompiles simple loop nest (because of bad AA caching?)

[via llvm-bugs]

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

            Bug ID: 42969
           Summary: LICM miscompiles simple loop nest (because of bad AA
                    caching?)
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: mattias.v.eriksson at ericsson.com
                CC: llvm-bugs at lists.llvm.org

This program has a load and a store which may alias in the inner loop. foo.c:

#include <stdio.h>

int a = 0;
int *b = &a;
int main() {
  for (int i = 0; i < 19; ++i) {
    for (int j = 0; j < 297; ++j) {
      a = *b + 1;
    }
  }

  printf("a = %d\n", a);
}

$ clang foo.c -O2 --target=i686-unknown-linux-gnu && ./a.out
a = 1

The correct value for a is 5643.

Using -opt-bisect-limit points to LICM:

clang foo.c -O2 --target=i686-unknown-linux-gnu -mllvm -opt-bisect-limit=84  &&
./a.out

...
BISECT: running pass (84) Loop Invariant Code Motion on loop
BISECT: NOT running pass (85) Loop Invariant Code Motion on loop
...
a = 5643


-print-after-all shows that the store to @a is moved out of the loop in LICM,
but the load via %0 remains inside (they may alias):

BEFORE:
for.body4:                                        ; preds =
%for.body4.preheader, %for.body4
  %j.012 = phi i32 [ %inc, %for.body4 ], [ %j.012.ph, %for.body4.preheader ]
  %5 = load i32, i32* %0, align 4, !tbaa !7
  %add = add nsw i32 %5, 1
  store i32 %add, i32* @a, align 4, !tbaa !7
  %inc = add nuw nsw i32 %j.012, 1
  %exitcond = icmp eq i32 %inc, 297
  br i1 %exitcond, label %for.cond.cleanup3, label %for.body4, !llvm.loop !18
}

LICM: Promoting value stored to in loop: @a = dso_local global i32 0, align 4

AFTER:
for.body4:                                        ; preds =
%for.body4.preheader, %for.body4
  %j.012 = phi i32 [ %inc, %for.body4 ], [ %j.012.ph, %for.body4.preheader ]
  %5 = load i32, i32* %0, align 4, !tbaa !7
  %add = add nsw i32 %5, 1
  %inc = add nuw nsw i32 %j.012, 1
  %exitcond = icmp eq i32 %inc, 297
  br i1 %exitcond, label %for.cond.cleanup3, label %for.body4, !llvm.loop !16

for.cond.cleanup3:                                ; preds = %for.body4
  %add.lcssa17 = phi i32 [ %add, %for.body4 ]
  %add.lcssa = phi i32 [ %add, %for.body4 ]
  %inc6 = add nuw nsw i32 %i.013, 1
  %exitcond14 = icmp eq i32 %inc6, 19
  br i1 %exitcond14, label %for.cond.cleanup, label %vector.memcheck

; Exit blocks
for.cond.cleanup:                                 ; preds = %for.cond.cleanup3
  %add.lcssa16 = phi i32 [ %add.lcssa17, %for.cond.cleanup3 ]
  %add.lcssa.lcssa = phi i32 [ %add.lcssa, %for.cond.cleanup3 ]
  store i32 %add.lcssa16, i32* @a, align 4, !tbaa !7
  %call = tail call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([8 x
i8], [8 x i8]* @.str, i32 0, i32 0), i32 %add.lcssa.lcssa)
  ret i32 0



I can't make a standalone run of "opt -licm" which does the faulty
transformation which makes me suspect that there is a bug in the caching in
Alias Set Tracker.

I experimented with using Memory SSA and this removes the problem:
$ clang -O2 foo.c --target=i686-unknown-linux-gnu -mllvm
-enable-mssa-loop-dependency=1 && ./a.out
a = 5643

Here is a Godbolt link: https://godbolt.org/z/0dYMZu
On Godbolt it miscompiles both on trunk and 8.0.0. Clang-7 works.

-- 
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/20190812/5c9a5748/attachment.html>