[NewGVN] Miscompile with equal instructions modulo attributes

[nunoplopes]

NewGVN miscompiles the following function:

@glb = external global i64, align 8

define i64 @src(i64 %tmp) {
  %conv3 = shl nuw i64 %tmp, 32
  store i64 %conv3, i64* @glb, align 8
  %sext = shl i64 %tmp, 32
  %r = lshr exact i64 %sext, 32
  ret i64 %r
}

define i64 @tgt(i64 %tmp) {
  %conv3 = shl i64 %tmp, 32
  store i64 %conv3, i64* @glb, align 8
  ret i64 %tmp
}

NewGVN hashes instructions ignoring attributes like 'nuw', so it assumes that conv3 and sext above are equivalent. But then it uses %conv3 as the leader, and then it calls InstSimplify with shl nuw & lshr extract and bug!

Test case from @regehr.
cc @alinas

[nunoplopes]

Another instance of the same bug. This one is more serious because it takes the inbounds attribute from a non-dominating BB.

define i1 @src(i32* %dst) {
entry:
  %dst.5 = getelementptr i32, i32* %dst, i64 5
  %dst.5.uge = icmp uge i32* %dst.5, %dst
  br i1 %dst.5.uge, label %then, label %else

then:
  %dst.6 = getelementptr i32, i32* %dst, i64 6
  %c.dst.6.uge = icmp uge i32* %dst.6, %dst
  ret i1 %c.dst.6.uge

else:
  %else.dst.6 = getelementptr inbounds i32, i32* %dst, i64 6
  %else.dst.6.uge = icmp uge i32* %else.dst.6, %dst
  ret i1 %else.dst.6.uge
}


define i1 @tgt(i32* %dst) {
  %dst.5 = getelementptr i32, i32* %dst, i64 5
  %dst.5.uge = icmp uge i32* %dst.5, %dst
  br i1 %dst.5.uge, label %then, label %else

then:
  ret i1 true

else:
  ret i1 true
}

https://llvm.godbolt.org/z/P79dGGszE

[nunoplopes]

Another one:

define void @src(i8 %start, i8 %high) {
  %start1 = add nsw i8 %start, 4
  %t1 = icmp ult i8 %start1, %high
  call void @use(i1 %t1)

  %start2 = add i8 %start, 4
  %t2 = icmp ult i8 %start2, %high
  call void @use(i1 %t2)
  ret void
}


define void @tgt(i8 %start, i8 %high) {
  %start1 = add nsw i8 %start, 4
  %t1 = icmp ult i8 %start1, %high
  call void @use(i1 %t1)
  call void @use(i1 %t1)
  ret void
}

declare void @use(i1)

[fhahn]

cc @fhahn

[nunoplopes]

InstSimplify has most rewrites that use nsw/nuw/exact attributes guarded by Q.IIQ.UseInstrInf && .... NewGVN sets that flag to false, so those rewrites don't kick in.
I see 5 rewrites that miss that check. Fixing those would only fix the first example though (where nuw from the leader is used). But it wouldn't fix the other 2 examples.
So I propose we get rid of this hack of UseInstrInf. It doesn't solve the root cause.

I guess the v1 fix would be to simply include the nsw/nuw/exact attributes in the GVN expression. Then we can work out if some selecting merging of classes by dropping attributes makes sense. Or some other heuristic.

[nunoplopes]

NewGVN does intercept the attributes when replacing an instruction with the leader. But it doesn't do that recursively. So it doesn't get the 3rd example, where t1/t2 are equal, except for their first operand that differs in nsw.
If we don't consider 'add' and 'add nsw' equivalent the problem is solved. Another way is to intercept attributes recursively. I would go with separate classes for v1.

[regehr]

here's a testcase for this bug that I like even better than the other ones:

@f = external global i64, align 8

define i64 @src(i64 %tmp) {
entry:
  %conv3 = shl nuw i64 %tmp, 32
  store i64 %conv3, i64* @f, align 8
  %sext = shl i64 %tmp, 32
  %0 = lshr i64 %sext, 32
  ret i64 %0
}

define i64 @tgt(i64 %tmp) {
entry:
  %conv3 = shl i64 %tmp, 32
  store i64 %conv3, i64* @f, align 8
  ret i64 %tmp
}

src(0x0000000100000000) -> 0
but
tgt(x0000000100000000) -> x0000000100000000