[LLVMbugs] [Bug 21759] New: [AArch64] Second LoopUnrollPass may cause compile-time regression with chained stores
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Fri Dec 5 07:15:50 PST 2014
http://llvm.org/bugs/show_bug.cgi?id=21759
Bug ID: 21759
Summary: [AArch64] Second LoopUnrollPass may cause compile-time
regression with chained stores
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: Backend: AArch64
Assignee: unassignedbugs at nondot.org
Reporter: mcrosier at codeaurora.org
CC: apazos at codeaurora.org, chandlerc at gmail.com,
james.molloy at arm.com, liujiangning1 at gmail.com,
llvmbugs at cs.uiuc.edu, t.p.northover at gmail.com
Classification: Unclassified
Created attachment 13437
--> http://llvm.org/bugs/attachment.cgi?id=13437&action=edit
Bad IR
Unfortunately, I can only reproduce this on our internal branch, but the
problem exists on mainline as well.
Given the following loop:
void foo (int a[])
{
int *ptr = a;
for (int i = 0; i <= 127; i++)
*ptr++ = 0xff;
}
Our internal branch will completely unroll the loop during the second call to
the LoopUnrollPass. The resulting IR (see attached bad.ll) causes a severe
compile-time regression when instruction selection begins recursively calling
WalkChainUsers in SelectionDAGISel.cpp.
If unrolling occurs during the first call to the LoopUnrollPass a later call to
InstCombine removes the chain by having all the gep use base + offset (see
attached bad.instcombine.ll).
I imagine the simplest solution would be to run InstCombine after the second
loop unrolling pass, but I'd like to get feedback before moving forward.
--
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/20141205/cd5a173b/attachment.html>
More information about the llvm-bugs
mailing list