This is an archive of the discontinued LLVM Phabricator instance.

Differential D119973

RegAllocGreedy: Fix last chance recolor assert in impossible case
ClosedPublic

Authored by arsenm on Feb 16 2022, 1:26 PM.

Download Raw Diff

Details

Reviewers

qcolombet
MatzeB
kparzysz
foad

Summary

This example is not compilable without handling eviction of specific
subregisters. Last chance recoloring was deciding it could try
evicting an overlapping superregister, which doesn't help make any
progress.The LiveIntervalUnion would then assert due to an overlapping
/ identical range when trying the new assignment.

Unfortunately this is also producing a verifier error after the
allocation fails. I've seen a number of these, and not sure if we
should just start deleting the function on error rather than trying to
figure out how to put together valid MIR.

I'm not super confident this is the right place to fix this. I also
have a number of failing testcases I need to fix by handling partial
evictions of superregisters.

Diff Detail

Unit TestsFailed

	Time	Test
	60,030 ms	x64 debian > MLIR.Examples/standalone::test.toy
	60,060 ms	x64 debian > libFuzzer.libFuzzer::large.test

Event Timeline

arsenm created this revision.Feb 16 2022, 1:26 PM

Herald added subscribers: kerbowa, hiraditya, jvesely. · View Herald TranscriptFeb 16 2022, 1:26 PM

arsenm requested review of this revision.Feb 16 2022, 1:26 PM

Herald added a project: Restricted Project. · View Herald TranscriptFeb 16 2022, 1:26 PM

Herald added a subscriber: wdng. · View Herald Transcript

The fix looks good to me.

Out-of-curiosity, do you hit the last recoloring heuristic often?

This revision is now accepted and ready to land.Feb 16 2022, 1:58 PM

In D119973#3327512, @qcolombet wrote:

The fix looks good to me.

Out-of-curiosity, do you hit the last recoloring heuristic often?

Not sure but I've been seeing a lot of failures recently in cases like this where it would only be satisfiable if superregisters can be partially spilled

Harbormaster completed remote builds in B150060: Diff 409386.Feb 16 2022, 3:02 PM

effc65eb1d167d6e6f9b8340cbb3b5ef6e2302a8

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.

In 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@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.

In D119973#3335190, @uabelho wrote:

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
}

Can you fill out more context with the surrounding instructions + ranges? Theoretically I can reconstruct the same scenario using -stress-regalloc

In D119973#3335710, @arsenm wrote:
In D119973#3335190, @uabelho wrote:
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
}
Can you fill out more context with the surrounding instructions + ranges? Theoretically I can reconstruct the same scenario using -stress-regalloc

So far by guessing I've only seen cases that fail to compile either way. However I'm guessing what we need is the assigned register is a strict superset of the interfering register

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.

I was wondering about that.
I think it could happen if each element of the super register is recolored as well. I.e., at the one point in the recoloring the super register becomes fully available.

In D119973#3335832, @arsenm wrote:
In D119973#3335710, @arsenm wrote:
In D119973#3335190, @uabelho wrote:
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
}
Can you fill out more context with the surrounding instructions + ranges? Theoretically I can reconstruct the same scenario using -stress-regalloc
So far by guessing I've only seen cases that fail to compile either way. However I'm guessing what we need is the assigned register is a strict superset of the interfering register

Does it work if you change regsOverlap to isSuperRegisterEq?

zero9178 added a subscriber: zero9178.Feb 21 2022, 11:44 AM

In D119973#3335940, @arsenm wrote:
In D119973#3335832, @arsenm wrote:
In D119973#3335710, @arsenm wrote:
In D119973#3335190, @uabelho wrote:
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
}
Can you fill out more context with the surrounding instructions + ranges? Theoretically I can reconstruct the same scenario using -stress-regalloc
So far by guessing I've only seen cases that fail to compile either way. However I'm guessing what we need is the assigned register is a strict superset of the interfering register
Does it work if you change regsOverlap to isSuperRegisterEq?

Changing

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

into

TRI->isSuperRegisterEq(VRM->getPhys(Intf->reg()), PhysReg)))) &&

does not help since Intf is

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

and we have this allocation

[%211 -> $b0] A

And we're examining if using b3210 for %237:Aquad would work.

b0 overlaps with b3210 so the test with regsOverlap makes mayRecolorAllInterferences bail out.
And b3210 is a super reg of b0, so using isSuperRegisterEq also makes mayRecolorAllInterferences bail out.

If you meant to try out

TRI->isSuperRegisterEq(PhysReg, VRM->getPhys(Intf->reg()))))) &&

then yes, that helps since b0 is not a super register of b3210.

I dumped LIS and VRM when entering tryLastChanceRecoloring and cut out and simplified what I think are the important parts:

%211 [912r,960r:0) 0@912r  weight:INF
%226 [920r,960r:0) 0@920r  weight:INF
%229 [928r,960r:0) 0@928r  weight:INF
%232 [932r,960r:0) 0@932r  weight:INF
%234 [940r,960r:0) 0@940r  weight:INF
%235 [944r,960r:1)[960r,968r:0) 0@960r 1@944r  weight:INF
%237 [952r,960r:0) 0@952r  weight:INF

[...]

912B	  %211:A = loadA %stack.4
920B	  %226:A = loadA %stack.6
928B	  %229:A = loadA %stack.8
932B	  %232:A = loadA %stack.10
940B	  %234:Aquad = loadAquad %stack.11
944B	  %235:Aquad = loadAquad %stack.12
952B	  %237:Aquad = loadAquad %stack.0

960B 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
}

968B      storeAquad %235:Aquad, %stack.12

[...]

[%234 -> $a3210] Aquad
[%235 -> $b7654] Aquad
[%211 -> $b0_32] A
[%226 -> $b3_32] A
[%229 -> $b2_32] A
[%232 -> $a4_32] A

And to repeat: with the new regsOverlap check we get:

Try to assign: %237 [952r,960r:0) 0@952r  weight:INF to $a3210
Early abort: the interference is not recolorable.
Some interferences cannot be recolored.
Try to assign: %237 [952r,960r:0) 0@952r  weight:INF to $b3210
Early abort: the interference is not recolorable.
Some interferences cannot be recolored.
Try to assign: %237 [952r,960r:0) 0@952r  weight:INF to $b7654
Early abort: the interference is not recolorable.
Some interferences cannot be recolored.
Try to assign: %237 [952r,960r:0) 0@952r  weight:INF to $a7654
Early abort: the interference is not recolorable.
Some interferences cannot be recolored.
LLVM ERROR: ran out of registers during register allocation

but before, without it, it also really explored the

Try to assign: %237 [952r,960r:0) 0@952r  weight:INF to $b3210

path, and finally succeeded since that way it could shuffle the fragmented free A registers around to form a free Aquad.

lkail added a subscriber: lkail.Feb 22 2022, 12:59 AM

I'm beginning to think that mayRecolorAllInterferences has no obligation to skip based on the register class / subregisters, and something else is wrong. The full interference checks are done later. The main failure I'm observing happens when trying to restore the allocation state after last chance recoloring fails. It ends up trying to restore the assignment of a register which is already allocated. I suspect something is going wrong when this is recursively called

Herald added a project: Restricted Project. · View Herald TranscriptMar 3 2022, 6:29 PM

In D119973#3358798, @arsenm wrote:

I'm beginning to think that mayRecolorAllInterferences has no obligation to skip based on the register class / subregisters, and something else is wrong. The full interference checks are done later. The main failure I'm observing happens when trying to restore the allocation state after last chance recoloring fails. It ends up trying to restore the assignment of a register which is already allocated. I suspect something is going wrong when this is recursively called

Not sure if it's what you are experiencing, but tryLastChanceRecoloring is broken in a few cases where "complicated" things have happened during the "try" part of it.

If recoloring fails, it tries to restore the state, but it does not restore e.g. splitting of vregs that happened.

So e.g. if one of the evicted vregs get splitted, then the allocator may end up in a corrupted state after the physreg is restored to the splitted vreg. The vreg may then have an empty live range but still have a physreg allocated, and this may later lead to a number of different assertions and crashes.

In D119973#3359120, @uabelho wrote:

In D119973#3358798, @arsenm wrote:

I'm beginning to think that mayRecolorAllInterferences has no obligation to skip based on the register class / subregisters, and something else is wrong. The full interference checks are done later. The main failure I'm observing happens when trying to restore the allocation state after last chance recoloring fails. It ends up trying to restore the assignment of a register which is already allocated. I suspect something is going wrong when this is recursively called

Not sure if it's what you are experiencing, but tryLastChanceRecoloring is broken in a few cases where "complicated" things have happened during the "try" part of it.

If recoloring fails, it tries to restore the state, but it does not restore e.g. splitting of vregs that happened.

So e.g. if one of the evicted vregs get splitted, then the allocator may end up in a corrupted state after the physreg is restored to the splitted vreg. The vreg may then have an empty live range but still have a physreg allocated, and this may later lead to a number of different assertions and crashes.

I think this is exactly what's happening

In D119973#3360529, @arsenm wrote:

In D119973#3359120, @uabelho wrote:

In D119973#3358798, @arsenm wrote:

I'm beginning to think that mayRecolorAllInterferences has no obligation to skip based on the register class / subregisters, and something else is wrong. The full interference checks are done later. The main failure I'm observing happens when trying to restore the allocation state after last chance recoloring fails. It ends up trying to restore the assignment of a register which is already allocated. I suspect something is going wrong when this is recursively called

Not sure if it's what you are experiencing, but tryLastChanceRecoloring is broken in a few cases where "complicated" things have happened during the "try" part of it.

If recoloring fails, it tries to restore the state, but it does not restore e.g. splitting of vregs that happened.

So e.g. if one of the evicted vregs get splitted, then the allocator may end up in a corrupted state after the physreg is restored to the splitted vreg. The vreg may then have an empty live range but still have a physreg allocated, and this may later lead to a number of different assertions and crashes.

I think this is exactly what's happening

I saw the revert in 8d66603a4. Thanks!

The complicated cases are indeed not well tested since it is very hard to hit them. I was hoping Matt's fix would avoid falling in one of them, while not preventing actual success. Looks like it wasn't the case.

So e.g. if one of the evicted vregs get splitted, then the allocator may end up in a corrupted state after the physreg is restored to the splitted vreg. The vreg may then have an empty live range but still have a physreg allocated, and this may later lead to a number of different assertions and crashes.

Is this what is happening here?
Would it be enough to drop the attempted recolored vreg when it has an empty range? (At this point, its live-range should be covered by the new split vregs)

In D119973#3392342, @qcolombet wrote:

The complicated cases are indeed not well tested since it is very hard to hit them. I was hoping Matt's fix would avoid falling in one of them, while not preventing actual success. Looks like it wasn't the case.

So e.g. if one of the evicted vregs get splitted, then the allocator may end up in a corrupted state after the physreg is restored to the splitted vreg. The vreg may then have an empty live range but still have a physreg allocated, and this may later lead to a number of different assertions and crashes.

Is this what is happening here?
Would it be enough to drop the attempted recolored vreg when it has an empty range? (At this point, its live-range should be covered by the new split vregs)

I'm still working on debugging this. I sort of see what's happening, but not really. At the point of failure, it's trying to unassign and reassign a register which was added to FixedRegisters after the initial interference check. It seems like the interference check needs to account for registers which will be added to FixedRegisters in the recursive calls. At the points those points are made, the ultimate parent register isn't in FixedRegisters for some reason.

In D119973#3392579, @arsenm wrote:

In D119973#3392342, @qcolombet wrote:

The complicated cases are indeed not well tested since it is very hard to hit them. I was hoping Matt's fix would avoid falling in one of them, while not preventing actual success. Looks like it wasn't the case.

So e.g. if one of the evicted vregs get splitted, then the allocator may end up in a corrupted state after the physreg is restored to the splitted vreg. The vreg may then have an empty live range but still have a physreg allocated, and this may later lead to a number of different assertions and crashes.

Is this what is happening here?
Would it be enough to drop the attempted recolored vreg when it has an empty range? (At this point, its live-range should be covered by the new split vregs)

I'm still working on debugging this. I sort of see what's happening, but not really. At the point of failure, it's trying to unassign and reassign a register which was added to FixedRegisters after the initial interference check. It seems like the interference check needs to account for registers which will be added to FixedRegisters in the recursive calls. At the points those points are made, the ultimate parent register isn't in FixedRegisters for some reason.

I can't articulate why, but changing the condition in mayRecolorAllInterferences to check if the stage is RS_Done or RS_Split also seems to work

In D119973#3394312, @arsenm wrote:

In D119973#3392579, @arsenm wrote:

In D119973#3392342, @qcolombet wrote:

The complicated cases are indeed not well tested since it is very hard to hit them. I was hoping Matt's fix would avoid falling in one of them, while not preventing actual success. Looks like it wasn't the case.

So e.g. if one of the evicted vregs get splitted, then the allocator may end up in a corrupted state after the physreg is restored to the splitted vreg. The vreg may then have an empty live range but still have a physreg allocated, and this may later lead to a number of different assertions and crashes.

Is this what is happening here?
Would it be enough to drop the attempted recolored vreg when it has an empty range? (At this point, its live-range should be covered by the new split vregs)

I'm still working on debugging this. I sort of see what's happening, but not really. At the point of failure, it's trying to unassign and reassign a register which was added to FixedRegisters after the initial interference check. It seems like the interference check needs to account for registers which will be added to FixedRegisters in the recursive calls. At the points those points are made, the ultimate parent register isn't in FixedRegisters for some reason.

I can't articulate why, but changing the condition in mayRecolorAllInterferences to check if the stage is RS_Done or RS_Split also seems to work

I think this just happens to hide it.

The problem is when you have multiple registers being recolored, and one of them succeeds and the other fails recoloring. The one that succeeded did further recoloring which is not rolled back on the failure of the second. It leaves behind registers assigned to registers which were temporarily freed up in the parent call. This needs to track much more of the allocation state to accurately roll back the recoloring attempt

In D119973#3397981, @arsenm wrote:

In D119973#3394312, @arsenm wrote:

In D119973#3392579, @arsenm wrote:

In D119973#3392342, @qcolombet wrote:

The complicated cases are indeed not well tested since it is very hard to hit them. I was hoping Matt's fix would avoid falling in one of them, while not preventing actual success. Looks like it wasn't the case.

So e.g. if one of the evicted vregs get splitted, then the allocator may end up in a corrupted state after the physreg is restored to the splitted vreg. The vreg may then have an empty live range but still have a physreg allocated, and this may later lead to a number of different assertions and crashes.

Is this what is happening here?
Would it be enough to drop the attempted recolored vreg when it has an empty range? (At this point, its live-range should be covered by the new split vregs)

I'm still working on debugging this. I sort of see what's happening, but not really. At the point of failure, it's trying to unassign and reassign a register which was added to FixedRegisters after the initial interference check. It seems like the interference check needs to account for registers which will be added to FixedRegisters in the recursive calls. At the points those points are made, the ultimate parent register isn't in FixedRegisters for some reason.

I can't articulate why, but changing the condition in mayRecolorAllInterferences to check if the stage is RS_Done or RS_Split also seems to work

I think this just happens to hide it.

The problem is when you have multiple registers being recolored, and one of them succeeds and the other fails recoloring. The one that succeeded did further recoloring which is not rolled back on the failure of the second. It leaves behind registers assigned to registers which were temporarily freed up in the parent call. This needs to track much more of the allocation state to accurately roll back the recoloring attempt

I now have another attempt which tracks a stack of successful recolorings that are rolled back on failure, rather than just the current depth's recolor candidates. However, the compile time is noticeably increased in my failing testcases (in a debug build one of them takes a full 15 seconds to complete) and it unexpectedly changes the output in a SystemZ test. I'm wondering if a better strategy would be to try avoiding recolor candidates that could conflict with the saved recoloring state for fixed registers

I'm wondering if a better strategy would be to try avoiding recolor candidates that could conflict with the saved recoloring state for fixed registers

If we go down that road, I'm pretty sure we will find cases where the recoloring was working previously and that would fail after such change.
The idea is while doing the recoloring we should have access to every color that is currently available.

I now have another attempt which tracks a stack of successful recolorings that are rolled back on failure

I haven't looked at that code for quite some time so I could totally mistaken, but that's conceptually already what is supposed to happen.

The order in which we roll back a particular "level" shouldn't matter. The stacking happens already naturally with the recursive calls.
IIRC we record the coloring of each register involved in the recoloring for each level (as materialized by the local variable in the call frame) and if it fails we put them back into this level pre-recoloring state.

The one that succeeded did further recoloring which is not rolled back on the failure of the second.

Hmm, that's weird, if one register fails within the same level, we should roll back the whole level to its previous state.

Hmm, that's weird, if one register fails within the same level, we should roll back the whole level to its previous state.

Oh I think I see what you mean!
When we successfully recolor part of a level, the recoloring that happened below that level is not rolled back.

Yeah, I could totally see that problem now. I think we've been lucky so far because on failure most levels probably have only register to recolor.

Replacement patch is D122580

Revision Contents

Path

Size

llvm/

lib/

CodeGen/

RegAllocGreedy.cpp

8 lines

test/

CodeGen/

AMDGPU/

regalloc-failure-overlapping-insert-assert.mir

62 lines

Diff 409386

llvm/lib/CodeGen/RegAllocGreedy.cpp

Show First 20 Lines • Show All 1,955 Lines • ▼ Show 20 Lines	if (Q.interferingVRegs(LastChanceRecoloringMaxInterference).size() >=
CutOffInfo \|= CO_Interf;		CutOffInfo \|= CO_Interf;
return false;		return false;
}		}
for (const LiveInterval *Intf : reverse(Q.interferingVRegs())) {		for (const LiveInterval *Intf : reverse(Q.interferingVRegs())) {
// If Intf is done and sit on the same register class as VirtReg,		// If Intf is done and sit on the same register class as VirtReg,
// it would not be recolorable as it is in the same state as VirtReg.		// it would not be recolorable as it is in the same state as VirtReg.
// However, if VirtReg has tied defs and Intf doesn't, then		// However, if VirtReg has tied defs and Intf doesn't, then
// there is still a point in examining if it can be recolorable.		// there is still a point in examining if it can be recolorable.
		//
		// Also, don't try to evict a register which is assigned to an overlapping
		// super register.
		//
		// TODO: Can we evict an interfering subset of the subregisters?
if (((ExtraInfo->getStage(*Intf) == RS_Done &&		if (((ExtraInfo->getStage(*Intf) == RS_Done &&
MRI->getRegClass(Intf->reg()) == CurRC) &&		(MRI->getRegClass(Intf->reg()) == CurRC \|\|
		TRI->regsOverlap(VRM->getPhys(Intf->reg()), PhysReg))) &&
!(hasTiedDef(MRI, VirtReg.reg()) &&		!(hasTiedDef(MRI, VirtReg.reg()) &&
!hasTiedDef(MRI, Intf->reg()))) \|\|		!hasTiedDef(MRI, Intf->reg()))) \|\|
FixedRegisters.count(Intf->reg())) {		FixedRegisters.count(Intf->reg())) {
LLVM_DEBUG(		LLVM_DEBUG(
dbgs() << "Early abort: the interference is not recolorable.\n");		dbgs() << "Early abort: the interference is not recolorable.\n");
return false;		return false;
}		}
RecoloringCandidates.insert(Intf);		RecoloringCandidates.insert(Intf);
▲ Show 20 Lines • Show All 809 Lines • Show Last 20 Lines

llvm/test/CodeGen/AMDGPU/regalloc-failure-overlapping-insert-assert.mir

This file was added.

				# RUN: not llc -march=amdgcn -mcpu=gfx908 -start-before=greedy,1 -stop-after=virtregrewriter,1 %s -o /dev/null 2>&1 \| FileCheck -check-prefix=ERR %s
				# RUN: not --crash llc -march=amdgcn -mcpu=gfx908 -verify-machineinstrs -start-before=greedy,1 -stop-after=virtregrewriter,1 %s -o /dev/null 2>&1 \| FileCheck -check-prefixes=ERR,VERIFIER %s

				# FIXME: We should not produce a verifier error after erroring

				# ERR: error: inline assembly requires more registers than available
				# VERIFIER: * Bad machine code: Using an undefined physical register *

				# This testcase cannot be compiled with the enforced register
				# budget. Previously, tryLastChanceRecoloring would assert here. It
				# was attempting to recolor a superregister with an overlapping
				# subregister over the same range.

				--- \|
				define void @foo() #0 {
				ret void
				}

				attributes #0 = { "amdgpu-waves-per-eu"="8,8" }

				...
				---
				name: foo
				tracksRegLiveness: true
				registers:
				- { id: 0, class: vgpr_32 }
				- { id: 1, class: vgpr_32 }
				- { id: 2, class: vreg_512 }
				- { id: 3, class: vreg_256 }
				- { id: 4, class: vreg_128 }
				- { id: 5, class: vreg_96 }
				- { id: 6, class: vreg_96 }
				- { id: 7, class: vreg_512 }
				- { id: 8, class: vreg_256 }
				- { id: 9, class: vreg_128 }
				- { id: 10, class: vreg_96 }
				- { id: 11, class: vreg_96 }
				- { id: 12, class: sreg_64 }
				- { id: 13, class: ccr_sgpr_64 }
				- { id: 14, class: vgpr_32 }
				machineFunctionInfo:
				scratchRSrcReg: '$sgpr0_sgpr1_sgpr2_sgpr3'
				frameOffsetReg: '$sgpr33'
				stackPtrOffsetReg: '$sgpr32'
				body: \|
				bb.0 (%ir-block.0):
				liveins: $sgpr30_sgpr31

				INLINEASM &"; def $0", 1 /* sideeffect attdialect /, 10 / regdef */, implicit-def $agpr0
				%14:vgpr_32 = COPY killed $agpr0
				INLINEASM &"; def $0 $1 $2 $3 $4", 1 /* sideeffect attdialect /, 16842762 / regdef:VReg_512 /, def %7, 14155786 / regdef:VReg_256 /, def %8, 5308426 / regdef:VReg_128 /, def %9, 3866634 / regdef:VReg_96 /, def %10, 3866634 / regdef:VReg_96 */, def %11
				INLINEASM &"; clobber", 1 /* sideeffect attdialect /, 12 / clobber /, implicit-def dead early-clobber $agpr0_agpr1_agpr2_agpr3_agpr4_agpr5_agpr6_agpr7_agpr8_agpr9_agpr10_agpr11_agpr12_agpr13_agpr14_agpr15_agpr16_agpr17_agpr18_agpr19_agpr20_agpr21_agpr22_agpr23_agpr24_agpr25_agpr26_agpr27_agpr28_agpr29_agpr30_agpr31, 12 / clobber */, implicit-def dead early-clobber $vgpr0_vgpr1_vgpr2_vgpr3_vgpr4_vgpr5_vgpr6_vgpr7_vgpr8_vgpr9_vgpr10_vgpr11_vgpr12_vgpr13_vgpr14_vgpr15_vgpr16_vgpr17_vgpr18_vgpr19_vgpr20_vgpr21_vgpr22_vgpr23_vgpr24_vgpr25_vgpr26_vgpr27_vgpr28_vgpr29_vgpr30_vgpr31
				INLINEASM &"; use $0", 1 /* sideeffect attdialect /, 16842761 / reguse:VReg_512 */, %7
				INLINEASM &"; use $0", 1 /* sideeffect attdialect /, 14155785 / reguse:VReg_256 */, %8
				INLINEASM &"; use $0", 1 /* sideeffect attdialect /, 5308425 / reguse:VReg_128 */, %9
				INLINEASM &"; use $0", 1 /* sideeffect attdialect /, 3866633 / reguse:VReg_96 */, %10
				INLINEASM &"; use $0", 1 /* sideeffect attdialect /, 3866633 / reguse:VReg_96 */, %11
				$agpr1 = COPY %14
				INLINEASM &"; use $0", 1 /* sideeffect attdialect /, 9 / reguse */, killed $agpr1
				S_SETPC_B64_return killed renamable $sgpr30_sgpr31

				...