https://llvm.org/bugs/show_bug.cgi?id=26373
Bug ID: 26373
Summary: LSR asserts trying to insert instructions at a
catchswitch
Product: new-bugs
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: andrew.kaylor at intel.com
CC: llvm-bugs at lists.llvm.org
Classification: Unclassified
Created attachment 15753
--> https://llvm.org/bugs/attachment.cgi?id=15753&action=edit
small reproducer
I've come across a case where an assertion fires in the loop strength reduction
pass because the instruction selected for an insertion point is a catchswitch
statement. In the failing test case, LSR is trying to replace a PHI node
(which happens to be in a catchswitch statement) and two of the incoming blocks
for this PHI node are catchswitch blocks. LSR does not currently attempt to
handle this case.
LSRInstance::RewriteForPHI() selects PN->getIncomingBlock(i)->getTerminator()
-- a catchswitch statement in the failing case -- as the insertion point and
calls LSRInstance::Expand() which in turn calls
LSRInstance::AdjustInsertPositionForExpand(), which is where the assertion
occurs.
assert(!isa<PHINode>(LowestIP) && !LowestIP->isEHPad()
&& !isa<DbgInfoIntrinsic>(LowestIP) &&
"Insertion point must be a normal instruction");
[at LoopStrengthReduce.cpp, line 4419 in r255921 of that file]
I used bugpoint to reduce the failing case and have attached the resulting IR
file. You should be able to reproduce the problem by running:
opt -loop-reduce lsr-catchswitch-insert.ll
--
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/20160129/7b821327/attachment.html>