[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


            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