[llvm-bugs] [Bug 35884] New: LoopDeletion causes an assert `use_empty() && "Uses remain when a value is destroyed!"'

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Jan 10 00:47:54 PST 2018


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

            Bug ID: 35884
           Summary: LoopDeletion causes an assert `use_empty() && "Uses
                    remain when a value is destroyed!"'
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
          Assignee: unassignedbugs at nondot.org
          Reporter: serguei.katkov at azul.com
                CC: llvm-bugs at lists.llvm.org

For the following simple reproducer:
define i64 @foo() {
entry:
  br label %badloop
badloop:
  %indvar1 = phi i64 [ 3, %entry ], [ %indvar2, %badloop_iter ]
  %check = icmp ult i64 %indvar1, 400
  br i1 %check, label %badloop_iter, label %loopexit
badloop_iter:
  %indvar2 = add i64 %indvar1, 1
  %baddef = add i64 0, 0
  br label %badloop
loopexit:
  ret i64 0
deadcode:
  ret i64 %baddef
}

> opt -S -loop-deletion test.ll

While deleting: i64 %baddef
Use still stuck around after Def is destroyed:  ret i64 %baddef
opt: ../../lib/IR/Value.cpp:92: llvm::Value::~Value(): Assertion `use_empty()
&& "Uses remain when a value is destroyed!"' failed.

The cause of this is that %baddef is defined in BB which does not dominate exit
and as a result LCCSA does not create a Phi node for it.

As a result LoopDeletion detects that loop is invariant and tries to delete it.

Assert happens when %baddef instruction is deleted due to it has use in
unreachable block.

The IR is well-formed because %baddef dominates all instructions in unreachable
block.

-- 
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/20180110/1d5b4175/attachment-0001.html>


More information about the llvm-bugs mailing list