| =================== |
| 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 |
