This is an archive of the discontinued LLVM Phabricator instance.

[regalloc] Fix assertion error when LiveInterval is empty
ClosedPublic

Authored by pcwang-thead on Jan 25 2022, 4:17 AM.

Details

Summary

When evicting interference, it causes an asseertion error
since LiveIntervals::intervalIsInOneMBB assumes that input
is not empty.

This patch fixed bug mentioned in D118020.

Diff Detail

Event Timeline

pcwang-thead requested review of this revision.Jan 25 2022, 4:17 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 25 2022, 4:17 AM

This seems odd to me.

llvm/lib/CodeGen/RegAllocGreedy.cpp
497–500

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)

This seems odd to me.

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.

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

MatzeB accepted this revision.Jan 25 2022, 12:38 PM

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

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

This revision is now accepted and ready to land.Jan 25 2022, 12:38 PM
This revision was landed with ongoing or failed builds.Jan 25 2022, 10:08 PM
This revision was automatically updated to reflect the committed changes.