llvm dev - Jun 2012 - [LLVMdev] Strong vs. default phi elimination and single-reg classes

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

On Jun 8, 2012, at 9:02 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> On Fri, 8 Jun 2012 08:49:32 -0700
> Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
>> 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.
> [We should add this to the docs somewhere].
http://llvm.org/bugs/show_bug.cgi?id=13058
>> 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.
That should be possible, yes.

/jakob

On Fri, 08 Jun 2012 09:24:16 -0700
Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
> 
> On Jun 8, 2012, at 9:02 AM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> > On Fri, 8 Jun 2012 08:49:32 -0700
> > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote:
> 
> >> 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.
> 
> > [We should add this to the docs somewhere].
> 
> http://llvm.org/bugs/show_bug.cgi?id=13058
> 
> >> 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.
> 
> That should be possible, yes.
As it turns out, I don't need to (the patterns in question are never
actually used in the current backend).

Furthermore, your suggestion to mark the register classes as
non-allocatable seems to have worked. Doing that and fully enabling this
now yields no (new) test-suite failures! :)

Thank you very much,
Hal
> 
> /jakob
> 


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