[LLVMbugs] [Bug 14879] New: "Ran out of registers during register allocation" for very constrained regclasses

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Jan 9 11:58:18 PST 2013


             Bug #: 14879
           Summary: "Ran out of registers during register allocation" for
                    very constrained regclasses
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: borja.ferav at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The following piece of code triggers an assertion in the Greedy regalloc for an
out of tree target:

struct ss
  int a;
  int b;
  int c;
void loop(struct ss *x, struct ss **y, int z)
  int i;
  for (i=0; i<z; ++i)
    x->c += y[i]->b;

The problem relies in the register classes for the load and store with
displacement instructions:
- load DREGS:$dst, PTR:$p
- store DREGS:$src, PTR:$p
where DREGS is a regclass composed of 16 registers and PTR is a regclass
composed of 2 registers, but the key point here is that PTR is a subset of
DREGS, so cross class copies are perfectly allowed.
One of the 2 registers in the PTR regclass is reserved for the frame
pointer, leaving only one register to access both x and y[i] in the code
above, which seems to confuse the regalloc. Implementing
getLargestLegalSuperClass() sort of helped for simpler functions, but not
for this one.
This code can be register-allocated if the addresses of both x and y[i] are
cross class copied to DREGS registers to temporarily store these values and
then when required copied back to the the register in PTR to access them in

To reproduce this bug with the Thumb2 target follow the steps described in the
second half of the following email:
This email also has an attachment with a dump of the error when using the
Thumb2 target.

As a hint, in this email I explain a possible workarond that potentially solves
the problem, although it might not be the perfect fix to solve the root of the

Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the llvm-bugs mailing list