llvm dev - Apr 2012 - [LLVMdev] Conceptual difference between "Unallocatable" and "Reserved" registers.

Hi,

I'm writing to ask the differences between a "reserved" register
and an
"unallocable" register. In X86 backend, for example, the stack pointer
register and instruction pointer are reserved but allocatable. In the
Doxygen document of function llvm::TargetRegisterInfo::getReservedRegs,
it says that a reserved register is one that *has particular uses and
should be considered unavailable at all times. *If it is unavailable at all
times, why not make such a reserved register unallocatable? Thanks!

Regards,
Lei Mou
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120418/6218aac7/attachment.html>

On Apr 17, 2012, at 9:09 PM, Lei Mou wrote:
> I'm writing to ask the differences between a "reserved"
register and an "unallocable" register. In X86 backend, for example,
the stack pointer register and instruction pointer are reserved but allocatable.
In the Doxygen document of function llvm::TargetRegisterInfo::getReservedRegs,
it says that a reserved register is one that has particular uses and should be
considered unavailable at all times. If it is unavailable at all times, why not
make such a reserved register unallocatable? Thanks!
Registers are partitioned into three disjoint sets:

1. Allocatable registers.
2. Reserved registers.
3. The rest: Unallocatable, unreserved registers.

The set of reserved registers is not known to TableGen, and it can vary for
different sub-targets, and even different functions. The reserved registers for
a function are computed by the TRI::getReservedRegs(MF) hook.

A register is allocatable if it belongs to at least one allocatable register
class AND it is not reserved.

See RegisterClassInfo.h, in particular the isAllocatable() function.

The third set of unallocatable, unreserved registers usually only contains the
flags. It is different from the reserved registers because the register
allocator is still tracking liveness of these registers. The reserved registers
are mostly ignored for liveness tracking.

/jakob

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

Thank you very much for the information!

Yours Sincerely,
Lei Mou

On Wed, Apr 18, 2012 at 11:03 PM, Jakob Stoklund Olesen <stoklund at
2pi.dk>wrote:
>
> On Apr 17, 2012, at 9:09 PM, Lei Mou wrote:
>
> I'm writing to ask the differences between a "reserved"
register and an
> "unallocable" register. In X86 backend, for example, the stack
pointer
> register and instruction pointer are reserved but allocatable. In the
> Doxygen document of function llvm::TargetRegisterInfo::getReservedRegs,
> it says that a reserved register is one that *has particular uses and
> should be considered unavailable at all times. *If it is unavailable at
> all times, why not make such a reserved register unallocatable? Thanks!
>
>
> Registers are partitioned into three disjoint sets:
>
> 1. Allocatable registers.
> 2. Reserved registers.
> 3. The rest: Unallocatable, unreserved registers.
>
> The set of reserved registers is not known to TableGen, and it can vary
> for different sub-targets, and even different functions. The reserved
> registers for a function are computed by the TRI::getReservedRegs(MF) hook.
>
> A register is allocatable if it belongs to at least one allocatable
> register class AND it is not reserved.
>
> See RegisterClassInfo.h, in particular the isAllocatable() function.
>
> The third set of unallocatable, unreserved registers usually only contains
> the flags. It is different from the reserved registers because the register
> allocator is still tracking liveness of these registers. The reserved
> registers are mostly ignored for liveness tracking.
>
> /jakob
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120419/cb3320a3/attachment.html>