First cut at the Code Generator using the TableGen methodology.

[oota-llvm.git] / docs / RegisterAllocatorInfo.txt

diff --git a/docs/RegisterAllocatorInfo.txt b/docs/RegisterAllocatorInfo.txt
index 557a2e597ddd6d67d21333c8d170900fec5f3cdd..446ffa1efadf400d4cd41b313f77570dd1de141a 100644 (file)
--- a/docs/RegisterAllocatorInfo.txt
+++ b/docs/RegisterAllocatorInfo.txt
@@ -34,7 +34,6 @@ Register allocation must be done  as:
 
 4. Input and Preconditions
 ==========================
-
 Register allocation is done using machine instructions. The constructor
 to the class takes a pointer to a method, a target machine description and
 a live variable information for the method.
@@ -50,6 +49,15 @@ The preconditions are:
 5. Assumptions
 ==============
 
+   All variables (llvm Values) are defined before they are used. However, a 
+   constant may not be defined in the machine instruction stream if it can be
+   used as an immediate value within a machine instruction. However, register
+   allocation does not have to worry about immediate constants since they
+   do not require registers.
+
+   Since an llvm Value has a list of uses associated, it is sufficient to
+   record only the defs in a Live Range.
+
 
 
 
@@ -69,6 +77,11 @@ Registerallocation consists of the following main steps:
 
 All the above methods are called from  PhyRegAlloc::allocateRegisters().
 
+All steps above except step 5 and suggesting colors in step 1 are indepenedent
+of a particular target architecture. Targer independent code is availble in
+../lib/CodeGen/RegAlloc. Target specific code for Sparc is available in
+../lib/Target/Sparc. 
+
 
 6.1. Construct Live-ranges & Suggest colors (machine specific) if required
 --------------------------------------------------------------------------
@@ -159,3 +172,26 @@ instructions that have been produced for that instruction by the register
 allocation (e.g., caller saving code)
 
 
+7. Furture work
+===============
+If it is necessary to port the register allocator to another architecture
+than Sparc, only the target specific code in ../lib/Target/Sparc needs to
+be rewritten. Methods defined in class MachineRegInfo must be provided for
+the new architecure.
+
+7.1 Using  ReservedColorList in RegClass
+----------------------------------------
+The register allocator allows reserving a set of registers - i.e. the reserved
+registers are not used by the register allocator. Currently, there are no
+reserved registers. It it is necessary to make some registers unavailable to
+a particular method, this feature will become handy. To do that, the reserved
+register list must be passed to the register allocator. See PhyRegAlloc.cpp
+
+
+7.2 %g registers on Sparc
+-------------------------
+Currently, %g registers are not allocated on Sparc. If it is necessary to
+allocate these %g registers, the enumeration of registers in SparcIntRegClass
+in SparcRegClassInfo.h must be changed. %g registers can be easily added as
+volatile registers just by moving them above in the eneumeration - see
+SparcRegClassInfo.h