LLVM ERROR: Error while trying to spill from class GPR: Cannot scavenge register without an emergency spill slot!

[chfast]

LLVM ERROR: Error while trying to spill X11 from class GPR: Cannot scavenge register without an emergency spill slot!
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.	Program arguments: /opt/compiler-explorer/clang-assertions-trunk/bin/llc -o /app/output.s -x86-asm-syntax=intel <source>
1.	Running pass 'Function Pass Manager' on module '<source>'.
2.	Running pass 'Prologue/Epilogue Insertion & Frame Finalization' on function '@f'
 #0 0x00000000033a6ed8 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x33a6ed8)
 #1 0x00000000033a47cc SignalHandler(int) Signals.cpp:0:0
 #2 0x00007f85af621420 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x14420)
 #3 0x00007f85af0e400b raise (/lib/x86_64-linux-gnu/libc.so.6+0x4300b)
 #4 0x00007f85af0c3859 abort (/lib/x86_64-linux-gnu/libc.so.6+0x22859)
 #5 0x00000000006952c7 (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x6952c7)
 #6 0x000000000288c7de llvm::RegScavenger::spill(llvm::Register, llvm::TargetRegisterClass const&, int, llvm::MachineInstrBundleIterator<llvm::MachineInstr, false>, llvm::MachineInstrBundleIterator<llvm::MachineInstr, false>&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x288c7de)
 #7 0x000000000288d031 llvm::RegScavenger::scavengeRegisterBackwards(llvm::TargetRegisterClass const&, llvm::MachineInstrBundleIterator<llvm::MachineInstr, false>, bool, int, bool) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x288d031)
 #8 0x000000000288e071 scavengeFrameVirtualRegsInBlock(llvm::MachineRegisterInfo&, llvm::RegScavenger&, llvm::MachineBasicBlock&) RegisterScavenging.cpp:0:0
 #9 0x000000000288e4c3 llvm::scavengeFrameVirtualRegs(llvm::MachineFunction&, llvm::RegScavenger&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x288e4c3)
#10 0x00000000027f74cc (anonymous namespace)::PEI::runOnMachineFunction(llvm::MachineFunction&) PrologEpilogInserter.cpp:0:0
#11 0x000000000268fde9 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#12 0x0000000002c05929 llvm::FPPassManager::runOnFunction(llvm::Function&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2c05929)
#13 0x0000000002c05b61 llvm::FPPassManager::runOnModule(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2c05b61)
#14 0x0000000002c06382 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x2c06382)
#15 0x000000000075eb22 compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#16 0x000000000069a786 main (/opt/compiler-explorer/clang-assertions-trunk/bin/llc+0x69a786)

target triple = "riscv64"

define i32 @f(i16 %0, ptr %A, ptr %G.8, i16 %LGV, ptr %G6, ptr %G1, i8 %L1, i8 %LGV2, ptr %G7, i64 %B, i64 %L, ptr %G5) {
BB:
  %A1 = alloca i64, i32 0, align 8
  %G53 = getelementptr ptr, ptr %A1, i16 256
  %G2 = getelementptr i16, ptr %G53, i64 -9223372036854775808
  %L9 = load i64, ptr null, align 4
  %G = getelementptr i32, ptr %G2, i1 true
  store ptr %G1, ptr %G, align 8
  %C3 = icmp slt i8 %L1, %LGV2
  store i64 %L9, ptr %G6, align 4
  %B712 = lshr i16 %0, %LGV
  store i16 %B712, ptr %G.8, align 2
  br label %BB1

BB1:                                              ; preds = %BB1, %BB
  br i1 %C3, label %BB1, label %BB4

BB4:                                              ; preds = %BB1
  store i16 %0, ptr %A, align 2
  %B4 = xor i64 %B, %L
  %G4 = getelementptr i64, ptr %G5, i64 %B4
  store i64 0, ptr %G7, align 4
  store ptr %G4, ptr null, align 8
  ret i32 0
}

https://godbolt.org/z/W3K59eq1h

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

[topperc]

I think the problem is %G41 = getelementptr i64, ptr %A, i16 256 which is accessing out bounds of the allocated stack. We estimate the stack size and use that to determine if a spill slot is needed. The stack size here is not large enough to need a spill slot. But then we access something out of bounds and can't calculate the address without a spill slot.

[chfast]

For the reference, similar bug can be found on Hexagon, Aarch64 and MIPS.

There is always an alloca involved but not always getelementptr.

[chfast]

It looks like 5f73d2b has "fixed" the reduced test case, but I will be able to provide some more.

[chfast]

Test case updated.