[llvm-commits] CVS: llvm/lib/Target/SparcV9/RegAlloc/Notes.txt
Chris Lattner
lattner at cs.uiuc.edu
Mon Aug 2 21:15:13 PDT 2004
Changes in directory llvm/lib/Target/SparcV9/RegAlloc:
Notes.txt added (r1.1)
---
Log message:
Move this file out of the top-level docs directory
---
Diffs of the changes: (+197 -0)
Index: llvm/lib/Target/SparcV9/RegAlloc/Notes.txt
diff -c /dev/null llvm/lib/Target/SparcV9/RegAlloc/Notes.txt:1.1
*** /dev/null Mon Aug 2 23:15:13 2004
--- llvm/lib/Target/SparcV9/RegAlloc/Notes.txt Mon Aug 2 23:15:02 2004
***************
*** 0 ****
--- 1,197 ----
+ ===================
+ Register Allocation
+ ===================
+
+
+ 1. Introduction
+ ===============
+
+ Purpose: This file contains implementation information about register
+ allocation.
+ Author : Ruchira Sasanka
+ Date : Dec 8, 2001
+
+
+ 2. Entry Point
+ ==============
+ class PhyRegAlloc (PhyRegAlloc.h) is the main class for the register
+ allocation. PhyRegAlloc::allocateRegisters() starts the register allocation
+ and contains the major steps for register allocation.
+
+ 2. Usage
+ ========
+ Register allocation must be done as:
+
+ MethodLiveVarInfo LVI(*MethodI ); // compute LV info
+ LVI.analyze();
+
+ TargetMachine &target = .... // target description
+
+
+ PhyRegAlloc PRA(*MethodI, target, &LVI); // allocate regs
+ PRA.allocateRegisters();
+
+
+ 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.
+
+ The preconditions are:
+
+ 1. Instruction selection is complete (i.e., machine instructions are
+ generated) for the method before the live variable analysis
+
+ 2. Phi elimination is complete.
+
+
+ 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.
+
+
+
+
+ 6. Overall Design
+ =================
+ There are sperate reigster classes - e.g., Int, Float,
+ IntConditionCode, FloatConditionCode register classes for Sparc.
+
+ Registerallocation consists of the following main steps:
+
+ 1. Construct Live-ranges & Suggest colors (machine specific) if required
+ 2. Create Interference graphs
+ 3. Coalescing live ranges
+ 4. Color all live ranges in each RegClass using graph coloring algo
+ 5. Insert additional (machine specific) code for calls/returns/incoming args
+ 6. Update instruction stream and insert spill code
+
+ 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
+ --------------------------------------------------------------------------
+ Live range construction is done using machine instructions. Since there must
+ be at least one definition for each variable in the machine instruction, we
+ consider only definitions in creating live ranges. After live range
+ construction is complete, there is a live range for all variables defined in
+ the instruction stream. Note however that, live ranges are not constructed for
+ constants which are not defined in the instruction stream.
+
+ A LiveRange is a set of Values (only defs) in that live range. Live range
+ construction is done in combination for all register classes. All the live
+ ranges for a method are entered to a LiveRangeMap which can be accessed using
+ any Value in the LiveRange.
+
+ After live ranges have been constructed, we call machine specific code to
+ suggest colors for speical live ranges. For instance, incoming args, call args,
+ return values must be placed in special registers for most architectures. By
+ suggesting colors for such special live ranges before we do the actual register
+ allocation using graph coloring, the graph coloring can try its best to assign
+ the required color for such special live ranges. This will reduce unnecessary
+ copy instructions needed to move values to special registers. However, there
+ is no guarantee that a live range will receive its suggested color. If the
+ live range does not receive the suggested color, we have to insert explicit
+ copy instructions to move the value into requred registers and its done in
+ step 5 above.
+
+ See LiveRange.h, LiveRangeInfo.h (and LiveRange.cpp, LiveRangeInfo.cpp) for
+ algorithms and details. See SparcRegInfo.cpp for suggesting colors for
+ 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 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
+ LiveRange has an adjacency list to record its neighbors. Live variable info
+ is used for finding the interferences.
+
+ See IGNode.h, InterferenceGraph.h (and IGNode.h, InterferenceGraph.h) for
+ data structures and PhyRegAlloc::createIGNodeListsAndIGs() for the starting
+ point for interference graph construction.
+
+
+ 6.3. Coalescing live ranges
+ ---------------------------
+ We coalesce live ranges to reduce the number of live ranges.
+
+ See LiveRangeInfo.h (and LiveRangeInfo.cpp). The entire algorithm for
+ coalesing is given in LiveRangeInfo::coalesceLRs().
+
+
+ 6.4. Color all live ranges in each RegClass using graph coloring algo
+ ---------------------------------------------------------------------
+ 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
+ is complete it is possible that some live ranges do not have colors (i.e.,
+ those that must be spilled).
+
+
+ 6.5. Insert additional (machine specific) code for calls/returns/incoming args
+ ------------------------------------------------------------------------------
+ This code is machine specific. Currently, the code for Sparc is implemented
+ in SparcRegInfo.cpp. This code is more complex because of the complex
+ requirements of assigning some values to special registers. When a special
+ value as an incoming argument receives a color through the graph coloring
+ 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 separately until the last
+ phase (see 6.6)
+
+
+ 6.6. Update instruction stream and insert spill code
+ -----------------------------------------------------
+ After we have assigned registers for all values and after we have produced
+ additional code to be inserted before some instructions, we update the
+ machine instruction stream. While we are updating the machine instruction
+ stream, if an instruction referes to a spilled value, we insert spill
+ instructions before/after that instruction. Also, we prepend/append additonal
+ 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
More information about the llvm-commits
mailing list