[llvm-bugs] [Bug 31122] New: [ARM] Assert in register allocation during last chance recoloring

[via llvm-bugs]

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

            Bug ID: 31122
           Summary: [ARM] Assert in register allocation during last chance
                    recoloring
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
          Assignee: unassignedbugs at nondot.org
          Reporter: ssijaric at codeaurora.org
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Created attachment 17634
  --> https://llvm.org/bugs/attachment.cgi?id=17634&action=edit
Test case for register allocation

There are two parts to this problem. Compiled using "llc -debug-only=regalloc
test.ll", the attached test case fails with

VirtRegMap.h:119: void llvm::VirtRegMap::clearVirt(unsigned int): Assertion
`Virt2PhysMap[virtReg] != NO_PHYS_REG && "attempt to clear a not assigned
virtual register"' failed.

The code looks like:

       %vreg647<def> = COPY %vreg645; QQQQPR_with_dsub_7_then_ssub_0:%vreg647
QQQQPR:%vreg645
        %vreg657<def> = COPY %vreg655; QQQQPR_with_dsub_7_then_ssub_0:%vreg657
QQQQPR:%vreg655
        %vreg679<def> = COPY %vreg678; QPR_VFP2:%vreg679 QPR:%vreg678
        %vreg657:dsub_7_then_ssub_0<def> = VDIVS %vreg679:ssub_2,
%vreg647:dsub_7_then_ssub_0, pred:14, pred:%noreg;
QQQQPR_with_dsub_7_then_ssub_0:%vreg657,%vreg647 QPR_VFP2:%vreg679
        %vreg659<def> = COPY %vreg657; QQQQPR:%vreg659
QQQQPR_with_dsub_7_then_ssub_0:%vreg657

This problem occurs during last chance recoloring, where %vreg679 doesn’t get
allocated (and is marked as not spillable), so last chance recoloring kicks in.
 It tries to allocate Q0 to %vreg679, where Q0 is assigned to %vreg647, which
interferes with %vreg679.  Upon trying to allocate a register to %vreg647,
%vreg679 gets evicted from Q0.  But %vreg679 is a fixed register, so it
shouldn’t get evicted.  Recoloring is thus deemed successful, and upon
returning from tryRecoloringCandidates, we assert when trying to unassign
%vreg679.  

I can get around this by moving the virtual register under consideration in
tryLastChanceRecoloring (%vreg679) to RS_Done stage right before the call to
tryRecolringCandidates, and then restoring the original stage afterward.  This
prevents the eviction of %vreg679 during recoloring.   Alternatively, I can
check FixedRegisters in canEvictInterference and return false.

After this assert is gone, I run into “LLVM ERROR: ran out of registers during
register allocation”. 

To get past this problem, we may need to spill an actual physical register to
free it up for %vreg679 if last chance recoloring fails.

-- 
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/20161122/4ff4d436/attachment-0001.html>