[llvm-bugs] [Bug 48058] New: [EarlyCSE] Assertion in EarlyCSE

via llvm-bugs llvm-bugs at lists.llvm.org
Tue Nov 3 01:29:04 PST 2020


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

            Bug ID: 48058
           Summary: [EarlyCSE] Assertion in EarlyCSE
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: chenzheng1030 at hotmail.com
                CC: llvm-bugs at lists.llvm.org

```
define i8 @nabs_different_constants(i8 %a) {
  %neg = sub i8 0, %a
  %cmp1 = icmp slt i8 %a, 0
  %cmp2 = icmp sge i8 %a, 0 
  %m1 = select i1 %cmp1, i8 %a, i8 %neg
  %m2 = select i1 %cmp2, i8 %neg, i8 %a
  %r = xor i8 %m2, %m1
  ret i8 %r
}
```

opt 6.ll -S -early-cse -earlycse-debug-hash

```
llvm-project/llvm/lib/Transforms/Scalar/EarlyCSE.cpp:433: static bool
llvm::DenseMapInfo<{anonymous}::SimpleValue>::isEqual({anonymous}::SimpleValue,
{anonymous}::SimpleValue): Assertion `!Result || (LHS.isSentinel() && LHS.Inst
== RHS.Inst) || getHashValueImpl(LHS) == getHashValueImpl(RHS)' failed.
```

Seems the requirement for same hash value for same semantic instruction is
quite fragile.
For above case, we get true return value for the two selects `%m1` and `%m2` in
`isEqualImpl`. But we get diff hash values for them in `getHashValueImpl`.
`%m1` is recognized as a ABS while `%m2` is not, so their hash values are
computed with different operands combination in `getHashValueImpl`.

If we want to add more equal patterns in `isEqualImpl`, it is quite hard to
ensure the hash values for same semantic instructions same for all cases. My
motivated case is to support following case:

```
define i64 @foo1(i16 %0, i64 %1, i64 %2) {

entry:
  %cmp1 = icmp ult i16 %0, 43
  %cond1 = select i1 %cmp1, i64 %1, i64 %2
  %cmp2 = icmp ugt i16 %0, 42
  %cond2 = select i1 %cmp2, i64 %2, i64 %1
  %ret = xor i64 %cond1, %cond2
  ret i64 %ret
}
```

we should be able to recognize that `%cond1` and `%cond2` are the same, so the
function should just return zero.

No idea about how to fix this. Need a more smart way to deal the hash values of
the equal instructions. Any thoughts?

-- 
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/20201103/a87c8a8f/attachment-0001.html>


More information about the llvm-bugs mailing list