COMP 412, Fall 2024 
Lab 2: Local Register Allocation 
Table of Contents Critical Dates for the Project 
1. Introduction 1 Code Due Date 10/23/2024 
2. Overview of the Problem 2 Code Check #1 Due 10/04/2024 
3. Code Specifications 3 Code Check #2 Due 10/16/2024 
5. Submitting Your Code 5 
6. Grading Rubric & Honor Policy 6 
Please report suspected typographical 
errors to the instructors via a message on 
the class Piazza site. 
7. Honor Policy 7 
A. ILOC Simulator & Subset 8 
B. Tools 10 
C. Timing Results from Prior Years 11 
D. Checklist for Lab 2 13 
1. Introduction 
In this programming assignment you will build a local register allocator—that is, a program that 
reads in a single block of ILOC code, transforms that block so that it uses a specified number of 
registers, and writes the transformed block out to the standard output stream. The input and 
output blocks are both written in the ILOC subset used in Lab 1. Section A.1 of this document 
describes the ILOC subset and its simulator. 
For the purposes of this lab, an input program and an output program are considered 
equivalent if and only if they print the same values in the same order to stdout and 
each data-memory location defined by an execution of the input program receives the 
same value when the output program executes. 
The output program may define additional memory locations that are not defined by 
the input program. In particular, it will define and use new locations to hold values that 
it decides to spill from registers to memory. 
The input blocks receive data in one of two ways. Either the values are is hard-coded into the 
block, or they are specified on the simulator’s command line using the -i command-line option. 
The concepts and algorithms behind register allocation are explained in two distinct places. 
First, there are a series of short videos available on the course Canvas Site. You should watch 
each of these videos. Second, Chapter 13 in the textbook explains register allocation in depth. 
Sections 13.1 and 13.2 provide background and Section 13.3 presents, in detail, the algorithms 
that pertain to Lab 2. You should read this material. An excerpt from Section 13.3 is posted on 
Canvas. (The later sections of Chapter 13 describe global allocation, the more complex problem 
that arises when the allocator looks at code that includes control-flow operations.) 
 Lab 2: Local Register Allocation Version 2024-1 
COMP 412     2         Fall 2024    
This document describes the specifications for your program, the policies for the lab, the 
various logistics associated with the lab, the process for submitting the lab, and the grading 
rubric. The document is long, but you should read it to ensure that you understand what is 
expected of your lab and what tools are available to help. 
2. Overview of the Problem 
A register allocator is a compiler pass that transforms a version of the program that uses an 
arbitrary number of registers into a version that uses a specified number of registers. That is, 
the input program might be written to use seventy-three registers and the output program can 
only use the number of registers available for application use on the target machine. 
The number of registers available for the output program is a parameter, called k, that is passed 
into the allocator on the command line. When invoked with a command line, such as 
 ./412alloc 17 ~comp412/students/ILOC/SLOCs/T001k.1 
The allocator should read the file, ~comp412/students/ILOC/SLOCs/T001k.i, determine if it is a 
valid ILOC block, and produce an equivalent block that uses at most 17 registers. 
To transform the program, the register allocator reads through the operations in the block and 
makes, at each operation, a decision as to which values should remain in registers and which 
values should be relegated to storage in memory. It inserts stores (spills) and loads (restores) as 
necessary to ensure that the values are in the right places. It rewrites the code to use the 
names of the actual hardware registers (r0 through r16 for the example command line). 
Your allocator may not apply optimizations other than register allocation. All the loads, stores, 
and arithmetic operations that appear in the input program must appear in the output 
program, in the same relative order.
1
 The output block must perform the original computation; 
it cannot pre-compute the results. Allocators that perform optimizations other than register 
allocation will lose substantial credit. Of course, the output block may use different register 
names than the input block. 
Your allocator may remove nops; they have no effect on the equivalence of the input and 
output of programs. If your allocator performs rematerialization (see the Lab 2 Performance 
Lecture), then it may move loadI operations around in ways that cannot happen with a load or 
a store. Finally, your allocator must not perform optimizations based on the input constants 
specified in ILOC test block comments; the autograder may use different input values to test 
your code. 
To evaluate your submission, we will use an autograder — a fairly-straightforward python 
program that will unpack your submission, perform any actions needed to build the executable, 
and test your executable against a series of test blocks. We will provide a distribution of the 
autograder so that you can verify that your submission works with the autograder. The 
production autograder will use additional files, not available in the distributed autograder, to 
assess your submission. 
     1
 We say “relative order” because the allocator may insert spills and/or restores between any two 
operations in the original program. Lab 2: Local Register Allocation Version 2024-1 
COMP 412     3         Fall 2024    
3. Code Specifications 
Your allocator must adhere to the following specifications. 
• Name: The executable version of your allocator must be named 412alloc. 
• Behavior: Your allocator must work in following three modes: 
412alloc -h When passed the -h flag, 412alloc must print a list of the valid commandline
 arguments that it accepts, along with a concise explanation for that option. That list 
should include the arguments described in this table, as well as any others that your 
allocator supports. After printing the message, 412alloc should sto. 
412alloc -x <name> The -x flag will only be used for Code Check 1. Again, <name> 
is a Linux pathname. With this flag, 412alloc should scan and parse the input block. It 
should then perform renaming on the code in the input block and print the results to 
the standard output stream (stdout). lab2_ref does not implement the -x flag. 
412alloc k <name> In this format, k is the number of registers available to the 
allocator (3 ≤ k ≤ 64) and <name> is a Linux pathname to the file containing the input 
block. The pathname can be either a relative pathname or an absolute pathname. 
If k is outside the valid range or it cannot open the file specified by <name>, 412alloc 
should print a reasonable error message and exit cleanly (e.g., no backtrace). 
If the parameters are valid, 412alloc should scan parse, and allocate the code in the 
input block so that it uses only registers r0 to rk-1 and print the resulting code to the 
standard output stream (stdout). 
In each mode, 412alloc should check the input parameters and report any problems on the 
standard error stream (stderr). All error messages should be printed to the standard error 
stream (stderr). Normal output should be printed to the standard output stream (stdout). 
• Input File: The input file will consist of a sequence of ILOC operations (a block) in the subset 
described in § A. If 412alloc cannot read the input file, or the code in the file is not valid 
ILOC, it should write an error message to the standard error file (stderr). 412alloc should 
detect as many errors in the file as it can before quitting. 
If the ILOC code in the input block uses a value from a register that has no prior definition, 
your allocator should handle the situation gracefully. 
Scanning and Parsing: Your register allocator should use your front end from Lab 1 to read 
and parse the input file. The front end should be prepared to handle large input files, such 
as the file T128k.i from Lab 1 (also found in ~comp412/students/ILOC/Scalability/SLOCs/). 
Makefile & Shell Script: As in Lab 1, you will submit a tar archive file that contains the 
source code for your allocator, along with any scripts or Makefiles required to create and 
execute the final code.2
 For a Java lab, you must submit the code, not a jar file. 
     2
 If you prefer to use another build manager (available on CLEAR), invoke that build manager in your Makefile. Your 
build manager should not leave behind a repository— particularly hidden files in comp412’s home directory. Lab 2: Local Register Allocation Version 2024-1 
COMP 412     4         Fall 2024    
Lab 2 submissions written in languages that require a compilation step, such as C, C++, or 
Java, must include a Makefile. The autograder will invoke make with the two commands: 
 make clean 
 make build 
in that order. The clean target should remove any files from old attempts to build the 
executable. The build target should ensure that the 412alloc executable is ready to run. If 
your submission is written in a language that does not require compilation, such as python, 
then it does not need a Makefile. 
If your submission does not create a standalone executable named 412alloc, then it should 
include a shell script named 412alloc that accepts the required command-line arguments 
and passes them to the program. For example, a project written in python3
 named lab2.py 
could provide an shell script named 412alloc that includes the following instructions: 
 #!/bin/bash 
 python3 lab2.py $@ 
To invoke python2, you would use the command “python2” rather than “python3”. 
Similarly, a project written in Java with a jar file named lab2.jar or a class named lab2.class 
that contains the main function could provide, respectively, one of the following two 
executable shell scripts, naming it 412alloc. 
 #!/bin/bash #!/bin/bash 
 java -jar lab2.jar $@ java lab2 $@ 
To ensure that your 412alloc shell script is executable on a Linux system, execute the 
following command in the CLEAR directory where your 412alloc shell script resides: 
 chmod a+x 412alloc 
To avoid problems related to the translation of carriage return and line feed between 
Windows and Linux, we strongly recommend that you write your shell script and Makefile 
on CLEAR rather than on a Windows system (see also man dos2unix). 
• README: Your submission must include a file named README (uppercase letters, no suffix) 
that provides directions for building and invoking your allocator. Include a description of all 
command-line arguments required for Lab 2 as well as any additional command-line 
arguments that your allocator supports. The autograder expects that the first two lines of 
your README file are in the following format: 
 //NAME: <your name> 
 //NETID: <your netid> 
Note that there are no spaces after the slashes, and that the keywords NAME and NETID 
are in all capital letters. Your name should be capitalized normally. Your netid should be 
lowercase characters and numbers. 
    
3 Alternatively, you can write a python program that runs directly. As an example, see the lab 1 testing script on 
CLEAR. Its first line is a comment that tells the shell to invoke python; the main routine parses argv and argc. Lab 2: Local Register Allocation Version 2024-1 
COMP 412     5         Fall 2024    
• Programming Language: You may use any programming language provided on Rice’s CLEAR 
facility, except for Perl. Your goal should be to use a language that is available on CLEAR, in 
which you are comfortable programming, for which you have decent debugging tools, and 
that allows you to easily reuse code in Lab 3. When coding, be sure to target the version of 
your chosen programming language that is available on CLEAR. 
• USE CLEAR: Your submission must work on CLEAR. If the code must be translated (e.g., 
compiled, linked, turned into a jar or an a.out), that must happen on CLEAR. Test the code 
on CLEAR; test it in the distributed autograder. Students have, in previous years, found 
differences between language and library versions on their laptops and on CLEAR. 
4. Code Checks 
Lab 2 has two intermediate code checks. To pass a code check, you should run the appropriate 
script (see below) and submit a screen shot to the code check assignment on Canvas. The code 
checks are intended to keep your progress on track, time wise. You get full credit at the due 
date, half credit two days late, and no credit beyond two days late. Grace days do not apply. 
(The grading rubric is discussed in § 5.) 
Code Check #1: The due date for code check #1 is shown on page 1. To pass code check #1, 
412alloc must correctly scan, parse, perform register renaming, and print the resulting 
renamed ILOC block to stdout. The code check #1 script and test blocks are located on 
CLEAR in the directory ~comp412/students/lab2/code_check_1/. 
Code Check #2: The due date for code check #2 is shown on page 1. To pass code check #2, 
412alloc must correctly perform register allocation on a limited set of test blocks. (That is, 
the allocated code must produce the correct answers when run with only k registers on the 
ILOC simulator.) The code check #2 script and the test blocks are found in 
~comp412/students/lab2/code_check_2/. 
The code check directories on CLEAR contain a README file that describes how to invoke the 
code check script and interpret the results. As before, you may need an executable shell script 
that to conform to the interface. A working Makefile is not critical for the code checks, but we 
recommend that you create your Makefile or script before the first code check and use it while 
developing your code. 
5. Submitting Your Final Code 
Due date: The due date for your code submission is shown on page 1. All work is due at 
11:59PM on the specified day. Individual extensions to this deadline will not be granted. 
Early-Submission Bonus: Submissions received before the due date will receive a bonus of one 
semester point (1% of the final course grade). 
Late Penalty: Submissions received after the due date will receive a penalty of one semester 
point (1% of the final course grade). No code will be accepted after the date when the next 
project is made available. Lab 2: Local Register Allocation Version 2024-1 
COMP 412     6         Fall 2024    
Grace Days: To cover situations that inevitably arise, we will waive up to four days of late 
penalties per semester when computing your final COMP 412 grade. Note that we choose 
where those days apply, after all grades are complete. We will apply these “grace” days in a 
way that maximizes benefit to you. 
Submission Details: To submit your work, you must create a tar archive that contains your 
submission, including (1) the source code for the register allocator, (2) the Makefile and/or 
shell script, (3) the README file, and (4) any other files that are needed for the autograder to 
build and test your code. The tar file should unpack into the current working directory. The 
README, Makefile, and executable script, if any, must reside in that top-level directory. 
The document “NoteOnTarFiles.pdf”, available on the COMP 412 Canvas Site, provides more 
details about the structure of the submission file system and the tar archive. You can test 
your archive using the autograder. If your archive does not work with the autograder, that 
will reduce the points you receive in the conformance portion of the grading rubric. 
If your allocator does not work, include in your tar file a file named STATUS that contains a 
brief description of its current state. You may include ILOC files that your lab handles 
correctly and ILOC files that it handles incorrectly. List those file names in the STATUS file. 
Name the tar file with your Rice netid (e.g., if your netid is jed12, you would name the 
archive jed12.tar). To submit your tar file, move it to CLEAR and execute the command 
~comp412/bin/submit_2 <tar file name> 
The submit_2 script will create a copy of your tar archive, timestamp it, and send an email 
confirmation to you and to the comp412 email account (for record-keeping). You should 
keep the tar archive until the end of the semester to record what you submitted. 
6. Grading Rubric 
The Lab 2 grade accounts for 20% of your final COMP 412 grade. The code rubric is based on 
100 points, allocated as follows. Correctness and cycle count will be determined using the Lab 2 
ILOC simulator. 
• 10 points for passing code check #1 by its due date (see table on page 1). 5 points will be 
awarded for passing code check #1 within three days of the due date. No points for code 
check #1 will be awarded after that time. Grace days do not apply to this deadline. 
• 10 points for passing code check #2 by its due date (see table on page 1). 5 points will be 
awarded for passing code check #2 within three days of the due date. No points for code 
check #2 will be awarded after that time. Grace days do not apply do this deadline. 
• 10 points for conformance to the Lab 2 code specifications and submission requirements. 
• 30 points for correctness of the allocated code produced by the final submission. Here, 
correctness means that running the allocated code produces the correct answer. 
• 20 points for effectiveness, measured as the number of cycles required to run the 
allocated code produced by your final submission on the Lab 2 ILOC simulator. An 
allocator that gets within 10% of the cycle counts for lab2_ref will receive full credit for Lab 2: Local Register Allocation Version 2024-1 
COMP 412     7         Fall 2024    
effectiveness. You can use the spreadsheet Lab2SpreadSheet.xlsx, in the lab 2 
documents folder, to estimate effectiveness on the report blocks. The report blocks are a 
subset of the blocks used to grade your allocator. 
• 20 points for performance, split equally between scalability and efficiency. The autotimer 
measures performance using blocks from ~comp412/students/ILOC/Scalability/SLOCs. 
The autotimer is included with the distributed autograder. 
Scalability: The register allocator should display linear scaling — that is, a doubling of the 
input size should produce growth of no more than 2x in the runtime. You can see this by 
plotting runtime as a function of non-comment lines in the input file; do not use a 
logarithmic scale on either axis. 
Efficiency: The table below shows the measured runtime on block T128k.i required for full 
credit and the time that will produce zero credit. Runtimes between full credit and zero 
credit will receive partial credit, on a linear scale between the breakpoints. The specific 
breakpoints were determined by analyzing the lab 2 submissions from the Fall 2020 class. 
Language Full Credit No Credit 
 C £ 1.0 second ³ 2.0 seconds 
 C++ £ 2.0 second ³ 4.0 seconds 
 Java £ 4.75 seconds ³ 12.0 seconds 
 Python £ 8.0 seconds ³ 20.0 seconds 
 Go £ 1.0 second ³ 2.0 seconds 
For languages not shown in the table, the instructor will determine a set of breakpoints 
based on the language, its implementation, and, perhaps, some additional testing. 
7. Honor Policy 
Your submitted source code and README file must consist of code and/or text that you wrote, 
not edited or copied versions of code and/or text written by others or in collaboration with 
others. You may not look at COMP 412 code from past semesters. Your submitted code may 
not invoke the COMP 412 reference allocator, or any other allocator that you did not write. 
You are free to collaborate with current COMP 412 students when preparing your Makefile 
and/or shell script and to submit the results of your collaborative Makefile and/or shell script 
efforts. However, as indicated in the previous paragraph, all other Lab 2 code and text 
submitted must be your own work, not the result of a collaborative effort. You may not use 
tools based on generative AI to assist you in creating the code for your allocator. 
You are welcome to discuss Lab 2 with the COMP 412 staff and with students currently taking 
COMP 412. You are also encouraged to use the archive of test blocks produced by students in 
previous semesters. However, we ask that you not make your COMP 412 labs available to Lab 2: Local Register Allocation Version 2024-1 
COMP 412     8         Fall 2024    
students (other than COMP 412 TAs) in any form during or after this semester. We ask that you 
not place your code anywhere on the Internet that is viewable by others. 
Appendix A. ILOC Simulator & Subset 
ILOC Simulator: An ILOC simulator, its source, and documentation are available in the subtree 
under ~comp412/students/lab2 on CLEAR. The source code and documentation are available. 
If you need to build a private copy of the simulator, § 7.1 of the simulator documentation 
explains the various configuration options. 
The simulator builds and executes on CLEAR. You can either run the simulator from comp412’s 
directory or copy it into your local directory. You can build a copy to run on your laptop. It 
appears to work on other OS implementations but that is not guaranteed. Your allocator will be 
tested and graded on CLEAR, so you should be sure to test it on CLEAR. 
ILOC Subset: Lab 2 input and output files consist of a single basic block4 of code written in a 
subset of ILOC, detailed in the following table. ILOC is case-sensitive. 
Syntax Meaning Latency 
load r1 => r2 r2 ß MEM(r1) 3 
loadI x => r2 r2 ß x 1 
store r1 => r2 MEM(r2) ß r1 3 
add r1, r2 => r3 r3 ß r1 + r2 1 
sub r1, r2 => r3 r3 ß r1 - r2 1 
mult r1, r2 => r3 r3 ß r1 * r2 1 
lshift r1, r2 => r3 r3 ß r1 << r2 1 
rshift r1, r2 => r3 r3 ß r1 >> r2 1 
output x prints MEM(x) to stdout 1 
nop idle for one cycle 1 
All register names have an initial lowercase r followed immediately by a non-negative integer. 
Leading zeros in the register name are not significant; thus, r017 and r17 refer to the same 
register. Arguments that do not begin with r, which appear as x in the table above, are assumed 
to be non-negative integer constants in the range 0 to 231 – 1. The assignment arrow is 
composed of an equal sign followed by a greater than symbol, as shown (=>). 
Each ILOC operation in an input block must begin on a new line and be completely contained on 
that line.
5
 Whitespace is defined to be any combination of blanks and tabs. ILOC opcodes must 
     4
 A basic block is a maximal length sequence of straight-line (i.e., branch-free) code. We use the terms block and 
basic block interchangeably when the meaning is clear. 5
 Both Carriage returns (CR, \r, 0x0D) and line feeds (LF, \n, 0x0A) may appear as in end-of-line sequences. Lab 2: Local Register Allocation Version 2024-1 
COMP 412     9         Fall 2024    
be followed by whitespace. Whitespace preceding and following all other symbols is optional. 
Whitespace is not allowed within operation names, register names, or the assignment arrow. A 
double slash (//) indicates that the rest of the line is a comment and can be discarded. Empty 
lines and nops in input files may also be discarded. 
Memory Use in the ILOC Simulator: The ILOC simulator has separate address spaces for code 
and data. The code memory is not accessible to a running ILOC program; this unreasonable 
restriction avoids a class of errors in the allocated code that are quite difficult to debug. 
The simulator only supports word-aligned accesses—that is, the address must be evenly 
divisible by four. For this assignment, addresses above 32,767 are reserved for the register 
allocator to use as spill locations. Any values that an ILOC test block stores to memory (other 
than spills) must use an address between 0 and 32,764, inclusive. 
For more details, see the ILOC Simulator document, in ~comp412/students/lab2/simulator/ on 
CLEAR. 
Simulator Usage Example: If test1.i is in your present working directory, you can invoke the 
simulator on test1.i in the following manner to test your register allocator: 
/clear/courses/comp412/students/lab2/sim -r 5 -i 2048 1 2 3 < test1.i 
This command will cause the simulator to execute the instructions in test1.i, print the values 
corresponding to ILOC output instructions, and display the total number of cycles, operations, 
and instructions executed. 
The -r parameter is optional and restricts the number of registers the simulator will use. (In the 
example, the simulator only uses 5 registers, named r0, r1, r2, r3, and r4.). You can use the –r 
parameter to verify that code generated by your allocator uses at most k registers. You should 
not use -r when running the original (non-transformed) report and timing blocks. 
The -i parameter is used to fill memory, starting at the memory address indicated by the first 
argument that appears after -i, with the initial values listed after the memory address. The load 
and store operations available in the ILOC subset require word-aligned addresses (that is, 
addresses must be evenly divisible by 4). The example command line shown above initializes 
location 2048 to 1, location 2052 to 2, and location 2056 to 3. (If the first operation in block 
test1.i is "output 2048", the simulator will print the value 1 to stdout.) When computing 
addresses for new spill locations, your allocator must generate word-aligned addresses. 
The simulator’s -x parameter will be used to verify that your allocator passes the Lab 2 code 
check. For example, if your 412alloc implementation produces a file of renamed ILOC code 
called renamed_block.i, the following command can be used to check whether renaming was 
correctly performed: 
/clear/courses/comp412/students/lab2/sim -x < renamed_block.i 
See the ILOC simulator document for additional information about supported command-line 
options. (Note that the command-line options -d, -s, and -c are not relevant for Lab 2.) 
 Lab 2: Local Register Allocation Version 2024-1 
COMP 412     10         Fall 2024    
ILOC Input Blocks: A large collection of ILOC input blocks is available on CLEAR, in the directory 
~comp412/students/ILOC/. Each block has the //SIM INPUT: and //OUTPUT: specifications to 
allow the various testing scripts to check for correctness. If you experience problems with the 
input blocks, please submit bug reports to the course Piazza site. 
To estimate your allocator’s performance, you may want to use the report blocks, which are 
available on CLEAR in ~comp412/students/lab2/report/. The report blocks all appear in the 
production autograder’s test suite. The autotimer uses a subset of the blocks found on CLEAR in 
~comp412/students/ILOC/Scalability/SLOCs/. 
B. Tools 
B.1 Reference Allocator 
To help you understand the functioning of a local register allocator and to provide an exemplar 
for your implementation and debugging efforts, we provide a reference allocator, lab2_ref. The 
reference allocator is a C implementation of the allocator. It follows the basic outline of the 
algorithm presented in class; it pays careful attention to how it generates spill code. You can 
improve your understanding of register allocation by examining its output on small blocks. The 
output code includes comments that are intended to help you understand what it did. 
The reference allocator is an example. You do not need to duplicate its behavior, its results, or 
the allocations that it produces. 
You can use the reference allocator to determine how well your allocator performs in terms of 
effectiveness (the number of execution cycles that the simulator reports when it runs the code 
that your allocator generates) and efficiency (the runtime of your allocator itself). 
The COMP 412 reference allocator can be invoked on CLEAR as follows: 
~comp412/students/lab2/lab2_ref k <name> 
where k is an integer (3 £ k £ 64) that specifies the number of registers available to the 
allocator and <name> is a valid Linux pathname relative to the current working directory that 
names an input file. For a description of the complete set of flags supported by the COMP 412 
reference allocator, enter the following command on CLEAR: 
~comp412/students/lab2/lab2_ref –h 
Note that the COMP 412 reference allocator can only be run on CLEAR. 
B.2 Testing and Timing Scripts 
Scripts to test your allocator’s correctness and efficiency are available on CLEAR in the directory 
~comp412/students/lab2/. Directions are provided in the related README files. 
 Lab 2: Local Register Allocation Version 2024-1 
COMP 412     11         Fall 2024    
C. Timing Results from Prior Years 
The graphs below show the timing results for the fastest implementation written in each of C, 
C++, Java, Python, and Go, from Fall 2021. In addition, we include graphs for Ruby (2014), 
OCaml (2015), Haskell (2015), and R (2014). These graphs should provide you with a reasonable 
notion of what kind of efficiency a student can achieve in the allocator project. 
Note the units on the vertical axes of the graphs. They change significantly between languages. 
D. Checklist for Lab 2 
The following high-level checklist is provided to help you track your progress on Lab 2. 
£ Implement a bottom-up local register allocator based on the algorithm in § 13.3 of 
Engineering a Compiler, 3rd Edition, and the project videos. Submit your allocator by 
October 23, 2024. 
£ Use the ILOC simulator, described in § A-1, to ensure that the allocated code produced by 
your program is correct—that is, it produces an equivalent sequence of operations as 
described on page 1—and to measure the number of cycles that the ILOC simulator requires 
to execute the allocated block. A large library of ILOC test blocks is available for you to use 
when testing your allocator in comp412’s students/ILOC subtree on CLEAR. 
£ Test your allocator thoroughly on CLEAR. It will be graded on CLEAR. 
£ Ensure that your code passes Lab 2 code check #1. To pass the code check, your code must 
correctly scan, parse, perform register renaming, and print the resulting renamed ILOC 
block to stdout. To receive full credit, submit results that demonstrate that your allocator 
passes code check #1 on or before October 4, 2024. 
£ Ensure that your code passes Lab 2 code check #2. To pass the code check, your code must 
conform to the interface described in § 3 and must perform register allocation correctly and 
print the resulting allocated ILOC block to stdout. To receive full credit, submit results that 
demonstrate that your allocator passes code check #2 on or before October 16, 2024. 
£ Spend the rest of your time improving the effectiveness of the allocator, as measured by 
the number of cycles that the simulator reports when it runs the allocated code, and the 
efficiency of the allocator, as reported by the autotimer. 
To produce an effectiveness grade, we will run the allocator on each of the report blocks 
and on a set of private blocks. We will test each code with k set to 3, 4, 5, 6, 8, and 10. The 
number of points awarded to an allocator for effectiveness will be based on a comparison 
of the cycle counts produced by the allocator and the cycle counts produced by lab2_ref on 
the same input file and k value. 
 
Change History: 
2024-1 posted on 09/23/2024 
 
请加QQ：99515681  邮箱：99515681@qq.com   WX：codinghelp