[LLVMdev] problem trying to write an LLVM register-allocation pass

[Lang Hames]

Hi Susan,

RBP is used as the frame pointer on x86 (hence its automatic appearance in
your code), and shouldn't be allocated to any vreg in function bar.
Loading/saving RBP should be managed by the stack frame setup/teardown code.

If it doesn't already, your allocator should filter out reserved registers
(See MachineRegisterInfo::isReserved(unsigned preg)) when assigning
physregs.

ArrayRef<MCPhysReg> pregs = TRC->getRawAllocationOrder(&MF);
for (int i = 0; i < pregs.size(); ++i) {
  if (MRI->isReserved(pregs[i]))
    continue;
  // use preg...
}

You could also use the AllocationOrder class to simplify the task of
finding valid pregs, though it does require you to use VirtRegMap.

If you are already checking the reserved regs then I've misdiagnosed the
problem. I'd be happy to dig further if you can point me to a copy of your
allocator and a test case.

Cheers,
Lang.


On Thu, Nov 29, 2012 at 3:49 PM, Susan Horwitz <horwitz at cs.wisc.edu> wrote:

> I have a new problem: Register RBP is used in a function foo.  (I am not
> allocating RBP to any virtual register, the instances of RBP in function
> foo are in the machine code when my register allocator starts.)
>
> Function foo calls function bar.  Register RBP is not saved across the
> call, though it is live after the call.  Function bar includes a virtual
> register.  The code that I'm using to find the registers available to be
> allocated to that virtual register includes EBP in that available-preg set.
>  This is a disaster, since writing into EBP clobbers RBP.
>
> I tried to add code to save all live physical registers across calls, but
> I don't know how to get the appropriate TargetRegisterClass (needed to call
> CreateSpillStackObject).
>
> Is there a different way to save/restore RBP across calls?  Or a way to
> get its TargetRegisterClass?
>
> Susan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121130/faaa9e0c/attachment.html>