[PATCH] D119973: RegAllocGreedy: Fix last chance recolor assert in impossible case

[Mikael Holmén via Phabricator via llvm-commits]

uabelho added a comment.

In D119973#3334807 <https://reviews.llvm.org/D119973#3334807>, @uabelho wrote:

> I haven't looked into it yet, but we see cases of "ran out of registers during register allocation" with this patch, for code that compiled succesfully before.

Looked a bit at one failure. It's for our out of tree target so I can't share a reproducer but I'll try to roughly describe what is happening.

Our machine has 16 registers in the "A" regclass, a0-a7 and b0-b7. The registers can be address individually as a0, a1, ..., b7.
The registers can also be accessed as quads, e.g. a3210 is made up of a3, a2, a1 and a0.
There are only 4 quads: a3210, a7654, b3210 and b7654. We have a regclass "Aquads" for them.

In a failing example we have a bundle like this with heavy register use:

  BUNDLE [...] {
    inst1 %234:Aquad
    inst1 %235:Aquad
    undef %235.sub0:Aquad = inst2 %211:A, %237.sub0:Aquad
    undef %235.sub1:Aquad = inst2 %226:A, %237.sub1:Aquad
    undef %235.sub2:Aquad = inst2 %229:A, %237.sub0:Aquad
    undef %235.sub3:Aquad = inst2 %232:A, %237.sub1:Aquad
  }

It uses 3 Aquad and 4 A registers as input, so in total it uses 16 registers, which is exactly what we have.

When we reach last chance recoloring for %237:Aquad, we have so far done the following allocations for the vregs in the hard bundle:

  [%234 -> $a3210] Aquad
  [%232 -> $a4] A
  [%235 -> $b7654] Aquad
  [%211 -> $b0] A
  [%229 -> $b2] A
  [%226 -> $b3] A

So a5, a6, a7 and b1 are not used in the bundle, but we need a quad. I.e. we have a sufficient number of available registers for a quad, but they are fragmented.

Without the patch, the allocator goes on and tries to free up b3210, unassigning b0, b2 and b3 from %211, %229 and %226.
After some more work it finally succeeds.

But with this patch it stops when examining the interfering range

  %211 [912r,960r:0) 0 at 912r  weight:INF

since b0 (which is assigned to %211) overlaps with b3210, due to the new code

  TRI->regsOverlap(VRM->getPhys(Intf->reg()), PhysReg)

and then we end up with "ran out of registers".
So it really looks like the new check is too pessimistic in some way, making the allocator fail in cases where it previously could find an allocation.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D119973/new/

https://reviews.llvm.org/D119973