halide
HVX codegen error: "Cannot scavenge register without an emergency spill slot"
PR #7009 seems to have injected a failure in the LLVM backend for HVX (using ~today's top-of-tree LLVM):
LLVM ERROR: Error while trying to spill V18 from class HvxVR: Cannot scavenge register without an emergency spill slot!
https://symbolize.corp.google.com/r/?trace=7f15e4cd9347,7f15e4e321bf,56148694f83c,561485277e6d,561485278ecd,561485279b9b,561485279656,5614852792b7,5614851bb3d0,5614850bc91e,5614867268a1,56148672c1c0,561486726f0b,561483556969,56148358be90,561483579146,56148357984d,56148357b72c,56148358129c,56148333e49f,56148333d127,56148333d86b,561483297d8d,7f15e4cc5632,56148325a7a9&map=a471ca6425fd0899b57753b9a4272895:56147c800000-5614871a1c30,3ccc1600b9140e48da03ed16e0210354:7f15e4e1d000-7f15e4e34140,280088eab084c30a3992a9bce5c35b44:7f15e4c64000-7f15e4e033e0
*** SIGABRT received by PID 2172107 (TID 2172107) on cpu 39 from PID 2172107; stack trace: ***
PC: @ 0x7f15e4cd9347 (unknown) gsignal
@ 0x561486fdf6d1 960 FailureSignalHandler()
@ 0x7f15e4e321c0 1393963584 (unknown)
@ 0x56148694f83d 224 llvm::report_fatal_error()
@ 0x561485277e6e 496 llvm::RegScavenger::spill()
@ 0x561485278ece 320 llvm::RegScavenger::scavengeRegisterBackwards()
@ 0x561485279b9c 112 scavengeVReg()
@ 0x561485279657 112 scavengeFrameVirtualRegsInBlock()
@ 0x5614852792b8 80 llvm::scavengeFrameVirtualRegs()
@ 0x5614851bb3d1 1440 (anonymous namespace)::PEI::runOnMachineFunction()
@ 0x5614850bc91f 976 llvm::MachineFunctionPass::runOnFunction()
@ 0x5614867268a2 192 llvm::FPPassManager::runOnFunction()
@ 0x56148672c1c1 48 llvm::FPPassManager::runOnModule()
@ 0x561486726f0c 208 llvm::legacy::PassManagerImpl::run()
I've never seen this one before. Unfortunately, the only place I'm seeing the failure (so far) is in one specific Generator inside Google... which is both extremely complicated and unsharable in unmodified form. I'm going to try to get something simplified enough to share, but in the meantime, is there any actionable debugging that can be done just with the stack trace?
@steven-johnson - See #7081 . @rootjalex's testcase passed with LLVM trunk but not LLVM 15. Is moving to trunk an option for you guys?
Google builds exclusively using close-to-trunk LLVM in this case, so we saw it with trunk as of mid-September 2022 -- if it's no longer happening in trunk, it must be fixed?
Perhaps. Checking commit logs in LLVM to see if our guys uploaded anything that sounds like a potential fix.
