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

[Hal Finkel]

On Fri, 8 Jun 2012 08:49:32 -0700
Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:

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

FYI: I just committed the relevant code (disabled by default); and I
submitted a bug to track this issue:
http://llvm.org/bugs/show_bug.cgi?id=13057
(It seems that I was doing this as you were responding to my e-mail, so
it may be out of date already).

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

Thanks for explaining! [We should add this to the docs somewhere].

> 
> Unfortunately, that breaks your TCRETURNri instructions. Sorry!

I'm guessing that I can rewrite TCRETURN to reference CTR/CTR8
directly. I'll have to try that.

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

Indeed, so it seems ;)

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

Thanks again,
Hal

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory