When evicting interference, it causes an asseertion error
since LiveIntervals::intervalIsInOneMBB assumes that input
is not empty.
This patch fixed bug mentioned in D118020.
Differential D118124
[regalloc] Fix assertion error when LiveInterval is empty • pcwang-thead on Jan 25 2022, 4:17 AM. Authored by
Details When evicting interference, it causes an asseertion error This patch fixed bug mentioned in D118020.
Diff Detail
Event TimelineComment Actions This seems odd to me.
Comment Actions I looked at this briefly. Here's the log leading up to one of the failures # Machine code for function f: NoPHIs, TracksLiveness, TiedOpsRewritten, TracksDebugUserValues Frame Objects: fi#0: size=8, align=8, at location [SP] 0B bb.0.entry: 16B FSD undef %4:fpr64, %stack.0, 0 :: (store (s64) into %stack.0) 32B %2:gpr = LW %stack.0, 0 :: (load (s32) from %stack.0, align 8) 48B %3:gpr = LW %stack.0, 4 :: (load (s32) from %stack.0 + 4, basealign 8) 64B $x10 = COPY %2:gpr 80B $x11 = COPY %3:gpr 96B PseudoRET implicit killed $x10, implicit killed $x11 # End machine code for function f. Enqueuing %2 AllocationOrder(GPR) = [ $x10 $x11 $x12 $x13 $x14 $x15 $x16 $x17 $x5 $x6 $x7 $x28 $x29 $x30 $x31 $x8 $x9 $x18 $x19 $x20 $x21 $x22 $x23 $x24 $x25 $x26 $x27 $x1 ] Enqueuing %3 Enqueuing %4 AllocationOrder(FPR64) = [ $f0_d $f1_d $f2_d $f3_d $f4_d $f5_d $f6_d $f7_d $f10_d $f11_d $f12_d $f13_d $f14_d $f15_d $f16_d $f17_d $f28_d $f29_d $f30_d $f31_d $f8_d $f9_d $f18_d $f19_d $f20_d $f21_d $f22_d $f23_d $f24_d $f25_d $f26_d $f27_d ] selectOrSplit GPR:%2 [32r,64r:0) 0@32r weight:4.675926e-03 w=4.675926e-03 AllocationOrder(GPR) = [ $x10 $x11 $x12 $x13 $x14 $x15 $x16 $x17 $x5 $x6 $x7 $x28 $x29 $x30 $x31 $x8 $x9 $x18 $x19 $x20 $x21 $x22 $x23 $x24 $x25 $x26 $x27 $x1 ] hints: $x10 assigning %2 to $x10: X10 [32r,64r:0) 0@32r selectOrSplit GPR:%3 [48r,80r:0) 0@48r weight:4.675926e-03 w=4.675926e-03 hints: $x11 assigning %3 to $x11: X11 [48r,80r:0) 0@48r selectOrSplit FPR64:%4 EMPTY weight:INF w=INF AllocationOrder(FPR64) = [ $f0_d $f1_d $f2_d $f3_d $f4_d $f5_d $f6_d $f7_d $f10_d $f11_d $f12_d $f13_d $f14_d $f15_d $f16_d $f17_d $f28_d $f29_d $f30_d $f31_d $f8_d $f9_d $f18_d $f19_d $f20_d $f21_d $f22_d $f23_d $f24_d $f25_d $f26_d $f27_d ] $f0_d is available at cost 1 Only trying the first 22 regs. The %4 virtual register is undef, but the first register in the allocation order has a cost > 0. With D118020, only register f8_d-f17_d have cost of 0. Comment Actions The thing that confuses me is that the very first thing in LiveRegMatrix::checkInterference() is this: if (VirtReg.empty()) return IK_Free; so I don't see how we would even reach the intervalIsInOneMBB test if the live interval is empty... Comment Actions Oh wait, I confused the intention of that if in canEvictInterferenceBasedOnCost. It's still odd to have the empty interval. But adding the check for empty() is fine with me then. LGTM |
If there are no live ranges in VirtReg then why didn't we bail out in the if 2 lines earlier? An empty liverange shouldn't interfere with anything. (I am also not sure how you end up with an empty life range in the first place, but I'd first investigate why the interference check did not end up returning IK_Free for you)