[llvm-bugs] [Bug 47238] New: [InstCombine] We need to recursively enqueue users of instructions whose use-count changed

[via llvm-bugs]

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

            Bug ID: 47238
           Summary: [InstCombine] We need to recursively enqueue users of
                    instructions whose use-count changed
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: lebedev.ri at gmail.com
                CC: llvm-bugs at lists.llvm.org

And i think we've finally found a fundamental issue :S
https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20200817/821034.html

While so far we've managed to get out of all the extra iterations by
consistently
enqueueing all the operands to be revisited, i'm not sure it's really that
simple.

Here, we have basically the following:

%i0 = cmp with non-canonical pred
%i1 = not %i0
%i2 = some-op %i0

First time around, we don't manage to fold the %i1 (by flipping cmp predicate),
because %i0 has other uses, but manage to fold away %i2, reducing use count of
%i0.
We do enqueue %i0, but that does us no good, because we need to revisit %i1,
which we don't during this iteration.

So basically, not only do we need to enqueue the values whose use-count
changed,
we also need to recursively enqueue users of these instructions.

-- 
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/20200819/009cec57/attachment.html>