[LLVMdev] Strong vs. default phi elimination and single-reg classes

[Jakob Stoklund Olesen]

On Jun 7, 2012, at 10:54 PM, Hal Finkel wrote:

> For example, sometimes LiveIntervals asserts with:
>                register:
> %CTR8
> clang: /llvm-trunk/lib/CodeGen/LiveIntervalAnalysis.cpp:446:
> void llvm::LiveInterval
> s::handlePhysicalRegisterDef(llvm::MachineBasicBlock*,
> llvm::MachineBasicBlock::iterator, llvm::SlotIndex,
> llvm::MachineOperand&, llvm::LiveInt erval&): Assertion
> `!isAllocatable(interval.reg) && "Physregs shouldn't be live out!"'
> failed.


When machine code is still in SSA form, there are restrictions on what can be done with physical registers, which by their nature can't be in SSA form. Lang and I have been trying to come up with some rules, but we haven't found the right set yet.

So far, we are enforcing:

- Allocatable registers cannot be live across basic blocks, except on entry to ABI blocks (the entry block and landing pads).

- Unallocatable registers may be live across basic blocks, but you can't use aliases. (For example, you can't define CTR8 in one block and read CTR in another).

- Reserved registers can do whatever you want, but defs are treated as having side effects, blocking certain optimizations like dead code elimination. (You don't want to DCE a stack pointer update).

In this case, the problem is that CTR and CTR8 are allocatable because CTRRC and CTRRC8 are allocatable. You can set 'isAllocatable = 0' in those register classes.

Unfortunately, that breaks your TCRETURNri instructions. Sorry!

Singleton register classes are dangerous because it is so easy to extend the live range of virtual registers without checking for interference. If you accidentally cross two live ranges, you get horrible spilling as you've seen. We try to use explicit unallocatable physreg liveness for singletons like X86::EFLAGS and ARM::CPSR, but isel and TableGen aren't making it easy.

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120608/2a681331/attachment.html>