fix typeo

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

diff --git a/docs/RegisterAllocatorInfo.txt b/docs/RegisterAllocatorInfo.txt
index 58a54505c16421988cea493b852a609fa2f8d101..b20b6350201d4f9ce8eb4035cae7e1d5a7149569 100644 (file)
--- a/docs/RegisterAllocatorInfo.txt
+++ b/docs/RegisterAllocatorInfo.txt
@@ -117,7 +117,7 @@ incoming/call arguments and return values.
 6.2. Create Interference graphs
 -------------------------------
 Once live ranges are constructed, we can build interference graphs for each
-register class. Though each register class must have a seperate interference
+register class. Though each register class must have a separate interference
 graph, building all interference graphs is performed in one pass. Also, the
 adjacency list for each live range is built in this phase. Consequently, each
 register class has an interference graph (which is a bit matrix) and each
@@ -139,7 +139,7 @@ coalesing is given in LiveRangeInfo::coalesceLRs().
 
 6.4. Color all live ranges in each RegClass using graph coloring algo
 ---------------------------------------------------------------------
-Each register class is colored seperately using the graph coloring algo. When
+Each register class is colored separately using the graph coloring algo. When
 assigning colors, preference is given to live ranges with suggested colors
 so that if such a live range receives a color (i.e., not spilled), then
 we try to assign the color suggested for that live range. When this phase
@@ -157,7 +157,7 @@ alogorithm, we have to make sure that it received the correct color (for
 instance the first incoming int argument must be colored to %i0 on Sparc). If
 it didn't receive the correct color, we have to insert instruction to to move
 the value to the required register. Also, this phase produces the caller 
-saving code. All adition code produced is kept seperately until the last
+saving code. All adition code produced is kept separately until the last
 phase (see 6.6)
 
 
@@ -173,10 +173,25 @@ 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.
 
-using  ReservedColorList in RegClass
\ No newline at end of file
+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