PPC can't spill CRC virtual registers

[hfinkel]

Bugzilla Link	11476
Resolution	FIXED
Resolved on	Dec 06, 2011 15:59
Version	trunk
OS	Linux
Attachments	Failing input
CC	@stoklund

Extended Description

Running llc (trunk 145766) on the attached input generates a crash because foldMemoryOperand is calling TargetInstrInfo::foldMemoryOperand which is calling PPCInstrInfo::storeRegToStackSlot with an invalid register number.

The actual backtrace is (abbreviated):
Unhandled reg in PPCRegisterInfo::getRegisterNumbering!
UNREACHABLE executed at /src/llvm-trunk-writable/lib/Target/PowerPC/MCTargetDesc/PPCBaseInfo.h:64!
...
#​2 0x0000000001533aa1 in llvm::llvm_unreachable_internal (msg=0x16cd920 "Unhandled reg in PPCRegisterInfo::getRegisterNumbering!",
file=0x16cd8c0 "/src/llvm-trunk-writable/lib/Target/PowerPC/MCTargetDesc/PPCBaseInfo.h", line=64)
at /src/llvm-trunk-writable/lib/Support/ErrorHandling.cpp:98
#​3 0x0000000000d38dda in getPPCRegisterNumbering (RegEnum=2147483882)
at /src/llvm-trunk-writable/lib/Target/PowerPC/MCTargetDesc/PPCBaseInfo.h:64
#​4 0x0000000000d3aad3 in llvm::PPCInstrInfo::StoreRegToStackSlot (this=0x2438730, MF=..., SrcReg=2147483882, isKill=false, FrameIdx=3, RC=0x1ef3e00, NewMIs=...)
at /src/llvm-trunk-writable/lib/Target/PowerPC/PPCInstrInfo.cpp:423
#​5 0x0000000000d3b01a in llvm::PPCInstrInfo::storeRegToStackSlot (this=0x2438730, MBB=..., MI=..., SrcReg=2147483882, isKill=false, FrameIdx=3, RC=0x1ef3e00,
TRI=0x2438758) at /src/llvm-trunk-writable/lib/Target/PowerPC/PPCInstrInfo.cpp:497
#​6 0x00000000011fb0dc in llvm::TargetInstrInfo::foldMemoryOperand (this=0x2438730, MI=..., Ops=..., FI=3)
at /src/llvm-trunk-writable/lib/CodeGen/TargetInstrInfoImpl.cpp:321
#​7 0x00000000012224aa in foldMemoryOperand (this=0x223c300, MI=..., Ops=..., LoadMI=0x0)
at /src/llvm-trunk-writable/lib/CodeGen/InlineSpiller.cpp:1044
#​8 0x00000000012230f1 in spillAroundUses (this=0x223c300, Reg=2147483881) at /src/llvm-trunk-writable/lib/CodeGen/InlineSpiller.cpp:1175
#​9 0x000000000122370b in spillAll (this=0x223c300) at /src/llvm-trunk-writable/lib/CodeGen/InlineSpiller.cpp:1238
#​10 0x0000000001223b8f in spill (this=0x223c300, edit=...) at /src/llvm-trunk-writable/lib/CodeGen/InlineSpiller.cpp:1286
#​11 0x00000000011625f5 in selectOrSplit (this=0x2450ad0, VirtReg=..., NewVRegs=...)
at /src/llvm-trunk-writable/lib/CodeGen/RegAllocGreedy.cpp:1593
#​12 0x000000000114e020 in llvm::RegAllocBase::allocatePhysRegs (this=0x2450af0) at /src/llvm-trunk-writable/lib/CodeGen/RegAllocBasic.cpp:322
#​13 0x0000000001162a21 in runOnMachineFunction (this=0x2450ad0, mf=...) at /src/llvm-trunk-writable/lib/CodeGen/RegAllocGreedy.cpp:1630
...
(gdb) up
#​3 0x0000000000d38dda in getPPCRegisterNumbering (RegEnum=2147483882)
at /src/llvm-trunk-writable/lib/Target/PowerPC/MCTargetDesc/PPCBaseInfo.h:64
64 llvm_unreachable("Unhandled reg in PPCRegisterInfo::getRegisterNumbering!");
(gdb) up
#​4 0x0000000000d3aad3 in llvm::PPCInstrInfo::StoreRegToStackSlot (this=0x2438730, MF=..., SrcReg=2147483882, isKill=false, FrameIdx=3, RC=0x1ef3e00, NewMIs=...)
at /src/llvm-trunk-writable/lib/Target/PowerPC/PPCInstrInfo.cpp:423
423 unsigned ShiftBits = getPPCRegisterNumbering(SrcReg)*4;
(gdb) up
#​5 0x0000000000d3b01a in llvm::PPCInstrInfo::storeRegToStackSlot (this=0x2438730, MBB=..., MI=..., SrcReg=2147483882, isKill=false, FrameIdx=3, RC=0x1ef3e00,
TRI=0x2438758) at /src/llvm-trunk-writable/lib/Target/PowerPC/PPCInstrInfo.cpp:497
497 if (StoreRegToStackSlot(MF, SrcReg, isKill, FrameIdx, RC, NewMIs)) {
(gdb) up
#​6 0x00000000011fb0dc in llvm::TargetInstrInfo::foldMemoryOperand (this=0x2438730, MI=..., Ops=..., FI=3)
at /src/llvm-trunk-writable/lib/CodeGen/TargetInstrInfoImpl.cpp:321
321 storeRegToStackSlot(*MBB, Pos, MO.getReg(), MO.isKill(), FI, RC, TRI);
...
(gdb) p *MI
$3 = (llvm::MachineInstr &) @​0x2695a68: {<llvm::ilist_nodellvm::MachineInstr> = {<llvm::ilist_half_nodellvm::MachineInstr> = {Prev = 0x284e660},
Next = 0x284e5b0}, MCID = 0x1e5c3a0, Flags = 0 '\000', AsmPrinterFlags = 0 '\000', Operands = std::vector of length 2, capacity 2 = {{OpKind = 0 '\000',
SubReg = 0 '\000', TargetFlags = 0 '\000', IsDef = true, IsImp = false, IsKill = false, IsDead = false, IsUndef = false, IsEarlyClobber = false,
IsDebug = false, SmallContents = {RegNo = 2147483881, OffsetLo = 2147483881}, ParentMI = 0x2695a68, Contents = {MBB = 0x2282008, CFP = 0x2282008,
CI = 0x2282008, ImmVal = 36184072, MD = 0x2282008, Sym = 0x2282008, Reg = {Prev = 0x2282008, Next = 0x24fe240}, OffsetedInfo = {Val = {Index = 36184072,
SymbolName = 0x2282008 "Б&\002", GV = 0x2282008, BA = 0x2282008}, OffsetHi = 38789696}}}, {OpKind = 0 '\000', SubReg = 0 '\000', TargetFlags = 0 '\000',
IsDef = false, IsImp = false, IsKill = false, IsDead = false, IsUndef = false, IsEarlyClobber = false, IsDebug = false, SmallContents = {RegNo = 2147483882,
OffsetLo = 2147483882}, ParentMI = 0x2695a68, Contents = {MBB = 0x249a308, CFP = 0x249a308, CI = 0x249a308, ImmVal = 38380296, MD = 0x249a308,
Sym = 0x249a308, Reg = {Prev = 0x249a308, Next = 0x0}, OffsetedInfo = {Val = {Index = 38380296, SymbolName = 0x249a308 "\360\221&\002", GV = 0x249a308,
BA = 0x249a308}, OffsetHi = 0}}}}, MemRefs = 0x0, MemRefsEnd = 0x0, Parent = 0x2618cb8, debugLoc = {LineCol = 0, ScopeIdx = 0}}

(so the MI being provided to TargetInstrInfo::foldMemoryOperand by foldMemoryOperand in InlineSpiller has a register with an invalid number (does that large number indicate a virtual register?))

0. Program arguments: llc -o /tmp/tscvec.s /tmp/tscvec.ll
1. Running pass 'Function Pass Manager' on module '/tmp/tscvec.ll'.
2. Running pass 'Greedy Register Allocator' on function '@s3110'

I've tried running this under valgrind on both linux/ppc64 and linux/x86_64, and the crash is the same on both systems, and on both systems, valgrind gives the process of clean bill of health.

[stoklund]

2147483882 is a normal virtual register. Clear the high bit to get the sequential %vreg number.

All virtual registers risk getting spilled, no exceptions. The target must be prepared to spill any virtual register that can be created.

In the case, the target fails to spill a CRRC virtual register.

It seems to be related to these command line options:

// FIXME (64-bit): Eventually enable by default.
namespace llvm {
cl::opt EnablePPC32RS("enable-ppc32-regscavenger",
cl::init(false),
cl::desc("Enable PPC32 register scavenger"),
cl::Hidden);
cl::opt EnablePPC64RS("enable-ppc64-regscavenger",
cl::init(false),
cl::desc("Enable PPC64 register scavenger"),
cl::Hidden);
}

[hfinkel]

Thanks for looking at this! Unfortunately, it seems that register scavenging on ppc64 is also broken, so I'll try to figure out how to fix it.

If I just use --enable-ppc64-regscavenger on the same test input, there are other crashes, for instance:
/src/llvm-trunk-writable/lib/CodeGen/RegisterScavenging.cpp:208: void llvm::RegScavenger::forward(): Assertion `SubUsed && "Using an undefined register!"' failed.
...
#​3 0x000000000118895f in llvm::RegScavenger::forward (this=0x26ad380) at /src/llvm-trunk-writable/lib/CodeGen/RegisterScavenging.cpp:208
#​4 0x0000000000c87648 in llvm::RegScavenger::forward (this=0x26ad380, I=...)
at /src/llvm-trunk-writable/include/llvm/CodeGen/RegisterScavenging.h:91
#​5 0x0000000001148da8 in llvm::PEI::replaceFrameIndices (this=0x2464150, Fn=...)
at /src/llvm-trunk-writable/lib/CodeGen/PrologEpilogInserter.cpp:800
#​6 0x0000000001146232 in llvm::PEI::runOnMachineFunction (this=0x2464150, Fn=...)
at /src/llvm-trunk-writable/lib/CodeGen/PrologEpilogInserter.cpp:120
#​7 0x0000000001104ca9 in llvm::MachineFunctionPass::runOnFunction (this=0x2464150, F=...)
at /src/llvm-trunk-writable/lib/CodeGen/MachineFunctionPass.cpp:33
#​8 0x00000000014d55b8 in llvm::FPPassManager::runOnFunction (this=0x2443f80, F=...)
at /src/llvm-trunk-writable/lib/VMCore/PassManager.cpp:1512
...
Can anyone provide an overview of where this was left off so I have some idea of how to approach fixing it? There are a bunch of FIXMEs in the code, but some big-picture help would be useful.

[stoklund]

It seems that spilling a CR register requires at least one scratch register, and sometimes two when the stack frame is too large.

The target is already reserving one register (r0/r2), so the register scavenger should only be needed in the large stack frame case.

The missing scratch register is unrelated to whether you are spilling a physreg or a virtreg, though. You should be able to do both in the small stack frame case.

[hfinkel]

Smaller testcase for a register scavenging problem
This crashes, as previously noted, when running llc with --enable-ppc64-regscavenger

[hfinkel]

The following seems to be happening in the small register scavenging failure:

• A call is made to PPCInstrInfo::StoreRegToStackSlot with a CR register. This results in the generation of a PPC::SPILL_CR pseudo instruction (for CR2).
• When PPCRegisterInfo::eliminateFrameIndex is called, it calls lowerCRSpilling on all of the PPC::SPILL_CR instructions.
• PPCRegisterInfo::lowerCRSpilling generates a call to the PPC MFCRpseud instruction (in this case, to save CR2 into the general-purpose register X6)
• When PEI::replaceFrameIndices tries to advance its RegScavenger instance past this MFCRpseud instruction (using RegScavenger::forward()), an assertion is triggered, because RegScavenger does not believe that CR2, or any of its subregisters, have been defined at that point.

Does anyone know how to fix this? CR2 is flags register, and, unless I'm thinking about this incorrectly, is always defined. How do I make RegScavenger understand that?

[stoklund]

A flag register is not necessarily always defined.

The machine code verifier implements the same liveness rules as the scavenger. Perhaps it will give you better error descriptions.

You may run it with -verify-machineinstrs or by calling MF.verify().

[hfinkel]

The underlying problem seems to be the generation of multiple consecutive SPILL_CR pseudo instructions for the same CR register. Looking at the source, it seems like this could happen if PPCInstrInfo::StoreRegToStackSlot is called to store multiple flags from the same register (because these are represented as separate "bit" registers in the CRBITRC register class).

Is there a clean way to fix this? I can certainly add some check to prevent emitting a SPILL_CR for some CR register if that would duplicate the previous instruction, but is there a better way?

[hfinkel]

You can ignore the question in my last comment; I figured out how to actually fix the duplicate SPILL_CR problem. Also, I've now enabled register scavenging by default. However, none of this actually fixed the original issue. The PPC target now does spill and restore CRRC virtual registers (at least in some cases). What function would be called to spill that CRRC virtual register that is misbehaving?

[hfinkel]

r145961 fixes this issue.