wrong code with opt "-memcpyopt -gvn"

[Quuxplusone]

Bugzilla Link	PR36940
Status	NEW
Importance	P enhancement
Reported by	Zhendong Su (su@cs.ucdavis.edu)
Reported on	2018-03-28 21:55:35 -0700
Last modified on	2018-03-29 17:38:40 -0700
Version	trunk
Hardware	PC All
CC	dberlin@dberlin.org, ditaliano@apple.com, efriedma@quicinc.com, gil.hur@sf.snu.ac.kr, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

$ clangpolly -v
clang version 7.0.0 (http://llvm.org/git/clang.git
9a41408814f37f4f864fb3e57aa01919b4d871d8) (llvm/trunk 328613)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/su/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.3.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/6.2.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Candidate multilib: x32;@mx32
Selected multilib: .;@m64
$
$ clangpolly -O0 small.c; ./a.out
$
$ clangpolly -O3 -mllvm -disable-llvm-optzns -c -emit-llvm -o small.bc small.c
$ optpolly -memcpyopt -gvn -o small-opt.bc small.bc
$ clangpolly small-opt.bc
$ ./a.out
Floating point exception (core dumped)
$

---------------------------------

int a, b, c, d, e, f = 1, g;

int main ()
{
  b = 1;
  while (1)
    {
      if (e > d)
    break;
      while (1)
    {
      int h = f % b;
      h = b;
      b = a;
      if (f)
        ;
      b = h;
    L:
      g = b;
      b = ~b;
      e = f ^ g ^ ~d;
      if (!b)
        break;
      b = ~c;
    }
    }
  return 0;
}

[Quuxplusone]

This is ... weird
it looks like memcpyopt reverses the pred order of two blocks?

--- small.ll    2018-03-28 22:17:48.000000000 -0700
+++ smallmem.ll 2018-03-28 22:18:04.000000000 -0700
@@ -1,4 +1,4 @@
-; ModuleID = 'small.bc'
+; ModuleID = 'small.ll'
 source_filename = "356940.c"
 target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-apple-macosx10.13.0"
@@ -20,7 +20,7 @@ define i32 @main() #0 {
   store i32 1, i32* @b, align 4, !tbaa !2
   br label %4

-; <label>:4:                                      ; preds = %0, %42
+; <label>:4:                                      ; preds = %42, %0
   %5 = load i32, i32* @e, align 4, !tbaa !2
   %6 = load i32, i32* @d, align 4, !tbaa !2
   %7 = icmp sgt i32 %5, %6
@@ -32,7 +32,7 @@ define i32 @main() #0 {
 ; <label>:9:                                      ; preds = %4
   br label %10

-; <label>:10:                                     ; preds = %9, %41
+; <label>:10:                                     ; preds = %41, %9
   %11 = bitcast i32* %2 to i8*
   call void @llvm.lifetime.start.p0i8(i64 4, i8* %11) #2
   %12 = load i32, i32* @f, align 4, !tbaa !2

But maybe that's just a red herring.
This also only fails when they are in the same invocation. If you run the
passes separately, it does fine.
Here is the diff:
--- small-gvn-nomem.ll  2018-03-28 22:19:45.000000000 -0700
+++ small-gvn-mem.ll    2018-03-28 22:20:29.000000000 -0700
@@ -1,4 +1,4 @@
-; ModuleID = 'small.ll'
+; ModuleID = 'small-mem.ll'
 source_filename = "356940.c"
 target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128"
 target triple = "x86_64-apple-macosx10.13.0"
@@ -52,10 +52,10 @@ define i32 @main() #0 {

 ; <label>:16:                                     ; preds = %15, %10
   store i32 %11, i32* @b, align 4, !tbaa !2
-  store i32 %11, i32* @g, align 4, !tbaa !2
+  store i32 %.pre3, i32* @g, align 4, !tbaa !2
   %17 = xor i32 %11, -1
   store i32 %17, i32* @b, align 4, !tbaa !2
-  %18 = xor i32 %.pre2, %11
+  %18 = xor i32 %.pre2, %.pre3
   %19 = xor i32 %.pre1, -1
   %20 = xor i32 %18, %19
   store i32 %20, i32* @e, align 4, !tbaa !2

So something is very off :)

the debug output difference is even weirder
@@ -57,7 +57,6 @@ GVN REMOVING NONLOCAL LOAD:   %17 = load
 GVN removed:   %17 = load i32, i32* @f, align 4, !tbaa !2
 GVN REMOVING NONLOCAL LOAD:   %20 = load i32, i32* %2, align 4, !tbaa !2
 GVN removed:   %20 = load i32, i32* %2, align 4, !tbaa !2
-GVN REMOVING NONLOCAL LOAD:   %20 = load i32, i32* @b, align 4, !tbaa !2
 GVN removed:   %20 = load i32, i32* @b, align 4, !tbaa !2
 GVN removed:   %20 = load i32, i32* @b, align 4, !tbaa !2
 GVN REMOVING NONLOCAL LOAD:   %21 = load i32, i32* @f, align 4, !tbaa !2

[Quuxplusone]

The pred order thing is a red herring; you're probably just getting weird results because you aren't using -preserve-ll-uselistorder, or something like that.

Probably something wrong with the caching in MemoryDependenceAnalysis; I can't think of any other way running memcpyopt first would influence GVN, given it isn't actually doing any transforms.