PP6: Register Allocation - Optimization

Transcription

1 PP6: Register Allocation - Optimization Date Due: 11/21/ :59pm 1 Goal In this project, you will improve the back end for your compiler by optimizing the code that it generates. The goal is to reduce the number of instructions executed by the program at runtime. There are two phases to this project. In the first phase, you will make basic improvements to register allocation by mapping memory locations to registers. In the second phase, which will be project 7, you will perform liveness analysis to further improve register allocation. Students in the honors section are required to implement at least one additional data-flow based optimization. 1.1 PP6 (58 points) In the project 6 phase you will improve register allocation. Register allocation is currently performed by the existing MIPS code generator in an extremely naive manner. Since every instruction can be executed using no more than three registers, the code generator reuses the same three registers and spills them after the execution of every operation. Of course, this scheme leaves 15 of the general purpose registers completely unused. You are to modify this code so that it makes better use of registers. Your first pass will assign each location to a specific register. In this manner, the value stored at a memory location can be used several times without unnecessarily loading and storing it each time. Of course, it is possible that we will run out of registers at some point. For this reason, you should always leave three registers unassigned. If you run out of registers, you can always fall back to using those three registers with the original allocation scheme of loading before and spilling after every instruction. Register allocation is easiest within a basic block where you know every instruction will execute in order. Therefore for this first phase you should automatically spill all locations at the end of every basic block. Of course, this negates many of the benefits of register allocation. In this phase, however, our goal is simply to set up a framework for register allocation and spilling. after we implement data-flow analysis in phase 2, we will be able to improve upon this basic technique. Note that we will not actually be creating basic block structures; instead we can simply recognize which instructions mark the end of a basic block: labels (as they provide a branch target), as well as any branching statements (IfZ, Goto). Return statements also end a basic block, as does the end of a function. However, in this case only global variables need to be spilled. Function calls do not necessarily end a basic block, but they do require spilling some registers: any global variables, as well as any caller-saves registers (t0 t9). You can avoid spilling registers at a function call by using callee-saves registers (s0 s7). However, before you use those registers you must first spill them; then you must make sure you load them when your function is done. This approach is a good trade-off if a location is live across several function calls. However, data-flow page 1

2 analysis is required to know if this is indeed the case. For that reason, use of callee-saves registers is optional for this first phase. Note that register allocation is also greatly complicated in the presence of aliasing (i.e. pointers or references). If there is more than one way to access a variable, then it becomes difficult to know when it can be kept in a register. Fortunately, in our language you cannot have pointers to local variables. On the other hand, fields in an object are only accessible via a pointer; however we actually have separate instructions (the Load and Store instruction) for writing to a field, so we can simply treat those specially in particular, a Load should always load its value, and a Store should always write its value. 1.2 PP7 Preview In the project 7 phase you will implement liveness analysis using the provided data flow analysis framework. Liveness analysis requires calculating which values are going to be used later (live values) and those which are not (dead values). You will use this information to improve register allocation by not spilling registers whose values are dead, and by allowing such registers to be reassigned to another location. Students in the honors section will also need to implement at least one additional data-flow optimization. page 2

3 2 Starter Files The starting files are posted on Piazza. For this project, you will also be provided the skeleton files for the data-flow analysis. The starting project contains the following files (the boldface entries are the ones you are most likely to modify; depending on your strategy you may modify others as well): Makefile builds project main.cc main() and some helper functions scanner.h/l our scanner interface/implementation parser.y yacc parser for Decaf (replace with your pp2 parser) ast.h/.cc interface/implementation of base AST node class ast type.h/.cc interface/implementation of AST type classes ast decl.h/.cc interface/implementation of AST declaration classes ast expr.h/.cc interface/implementation of AST expression classes ast stmt.h/.cc interface/implementation of AST statement classes codegen.h/.cc interface/implementation of CodeGenerator class tac.h/.cc interface/implementation of Tac class and subclasses mips.h/.cc interface/implementation of our TAC- MIPS translator cfg.h/.cc interface/implementation of a Control Flow Graph df base.h template base class for Data Flow Analysis classes errors.h/.cc error messages you are to use hashtable.h/.cc simple hashtable template class list.h simple list template class location.h utilities for handling locations, yylloc/yyltype utility.h/.cc interface/implementation of various utility functions samples/ directory of test input files run script to compile and execute result on SPIM simulator Copy the entire directory to your home directory. Use make to build the project. It reads input from stdin and you can use standard UNIX file redirection to read from a file and/or save the output to a file: % dcc <samples/program.decaf >program.asm The output is MIPS assembly that can be executed on the SPIM simulator. The spim executable, which actually executes the code, can be found on the project web site. You can either invoke it using the full path or add our bin directory to your path to use the short name. The -file argument allows you to specify the file of MIPS assembly to execute. spim -file program.asm 3 Implementation Here are some suggestions for implementing the project. page 3

4 3.1 Register Allocation The existing register allocation is implemented in mips.cc and mips.h. You should begin by reviewing the code to fully understand how the initial register allocation scheme. Note that the registers an instruction uses are hard-coded, and that each register is loaded immediately before use and (if modified) spilled immediately after use. Your first goal is to modify the allocator so that you can request a register for a given memory location. The allocator should check the existing registers to see if the location is already loaded in a register; if so, it should simply return that register. If the location is not already loaded, the allocator should pick an unused register, load the location into that register, and then return the register. Note that the M ips class (in mips.h/.cc) contains an array of structures which can be used to store information about a register. Use this array to remember what is in each register. Next, you want to avoid spilling as long as possible. Thus, instead of spilling immediately after an instruction you should simply mark any registers which need to be spilled as dirty. Later, when it s finally necessary to spill, you can spill all the dirty registers at once. (Later we may be able to avoid spilling altogether if the location is not used again later.) It is always possible that you will run out of registers. There are multiple ways to handle this situation. The simplest method is to simply reserve the original three registers to use as backup when all other registers are full. This is especially simple considering that each instruction is already hard-coded with a register to use. Thus, each request for a register can include a hard-coded backup register to use in case no registers are empty. Your allocator should simply spill that register (if it is dirty) and return it. 3.2 Data Flow Analysis A skeleton for a data flow analysis framework is provided in the project files. The framework is based on a control flow graph implementation found in cfg.h/.cc. This class is a data structure built from a sequence of TAC instructions representing a function. (Note we only build CFGs for functions.) The framework also includes two classes for accessing a CFG: a F orwardf low class for moving forward over the CFG, and a ReverseF low class for moving backward over the CFG. The DataF low class in df base.h/.cc is parameterized with two types: the type to associate with each instruction, and the flow class for walking over the CFG. So for example, a class to perform liveness analysis could be written as follows. typedef std::set<const Location*> LiveSet; class Liveness : public DataFlow<LiveSet, ControlFlowGraph::ReverseFlow> The basic analysis algorithm is implemented in the DataF low base class. However, you must override four pure virutal methods in order to tailor the algorithm to your particular analysis. Once you have performed the analysis you can easily retrieve the data value associated with each instruction. Note that data is associated with a TAC instruction, page 4

5 not a MIPS instruction. Thus, when outputting MIPS it is helpful to know which TAC instruction the MIPS is for. The Mips class has been augmented to maintain a pointer to the current instruction. 4 Grading When grading your project, we will use your compiler to compile a Decaf program, then use SPIM to execute the result. We will diff the output of your program with the expected output. Any differences will be penalized. Next we will compare the number of MIPS instructions executed when running your program. As discussed earlier, your improvements in register allocation should decreasing the number of instructions executed at runtime. Our version of SPIM includes a -count flag, which prints results about the number of instructions executed. spim -count -file t1.decaf You should use this feature to see how much your improved register allocator is improving the execution. Submit a README file briefly outlining your implementation and your basic design decisions. Also, briefly summarize experimental results noting which files benefited from your pass. Feel free to include your own decaf files with your submission, which help demonstrate your implementation s effectiveness. 5 Deliverables Electronically submit your entire project through CSNET. You should submit a tar.gz of the project directory. This does not mean a tarball of a separate zip file of the files in your project directory. page 5