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.
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.
+
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
--------------------------------------------------------------------------
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
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
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)
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
projects / oota-llvm.git / blobdiff