This is an archive of the discontinued LLVM Phabricator instance.

[NewGVN] Don't derive incorrect implications.
ClosedPublic

Authored by davide on May 1 2017, 2:11 PM.

Details

Summary

The problem is here (debug output):

Processing instruction   %tmp4 = icmp sgt i32 %tmp.0, 0
Created new congruence class for   %tmp4 = icmp sgt i32 %tmp.0, 0 using expression { ExpressionTypeConstant, opcode = 18,  constant = i1 true} at 4 and leader i1 true
New class 4 for expression { ExpressionTypeConstant, opcode = 18,  constant = i1 true}

we believe %tmp1 implies %tmp4

where:

br i1 %tmp1, label %bb2, label %bb7
br i1 %tmp4, label %bb5, label %bb7

because while looking at PredicateInfo stuffs we end up calling isImpliedTrueByMatchingCmp() with the operands swapped,
y less then x implies y less then or equal x but the other way around is not true.

The function has a very confusing name IMHO. I expect isImpliedTrueByMatchingCmp means that *the first argument* is implied by the second and not viceversa. I'm willing to change it, but I wonder if we have other latent bugs in tree because of this.

Diff Detail

Repository
rL LLVM

Event Timeline

davide created this revision.May 1 2017, 2:11 PM
dberlin accepted this revision.May 1 2017, 3:27 PM
This revision is now accepted and ready to land.May 1 2017, 3:27 PM
This revision was automatically updated to reflect the committed changes.