Your final assignment is to design or implement a research project of your own choice. This may involve extending one of the projects you've already implemented, or designing a project of your own choice. Since time is limited, you should not choose too ambitious a project. Don't try the impossible -- that what PhD dissertations are for.
A variety of interesting projects can be designed around code you've already implemented. For example, you might redo your register allocator, better handling literals or globals or temporaries. You might split live ranges (perhaps at loop boundaries) to improve coloring. You might modify your register allocator to handle caller-save/callee-save register classes. You might include Appel/George register coalescing. You might devise different spill heuristics, and decide if Chaitin's can be improved upon.
In some cases it is easier to recompute a register value than to spill it into memory and later reload it (this is called rematerialization). For example, if a+b is loaded into register R and both a and b are register resident, then spilling a+b is unnecessary, since it can be recomputed in one instruction. Rematerialization also affects loop invariant code motion; if recomputation is cheap, why bother to avoid it? Using profiling, you might study how much code optimization improves when accurate cost values (rather than static cost estimates) are used.
You might investigate code scheduling by modifying the code generator to reorder generated code to minimize pipeline stalls. You might consider scheduling for multiple issue Sparc architectures (like the SuperSparc and UltraSparc). The interaction of loop unrolling and software pipelining might be studied.
Consider improving your loop invariant optimization by including profitability issues. You might study the interplay between value reuse (literals, loop invariants and redundant expressions) and register allocation. That is, to reuse values, you want to put them in registers, but the more register candidates you create, the harder it is to satisfy all register requests. (Rematerialization is an issue here.)
Cache behavior (both I and D cache) is a major factor in program performance. What changes to data or instruction layout enhance cache performance? Can you estimate the cache needs of a program? How should a program be recompiled when you upgrade to an identical processor with a larger or better cache?
Transactional memories are currently a popular research topic. How should programming languages like C++, C# and Java be modified to utilize transactions? Can compilers recognize program fragments that may be run concurrently using transactional memory? Can locks be replaced or simplified if interfering threads are automatically aborted?
Multi-core processors are becoming common. How can compilers use the extra "free" threads they provide? Can security and reliability be improved by doing extra checking or redundant computations? Can a program be automatically split into several cooperating threads to deter unauthorized program modifications? Can extra threads support transactional memories (which usually require software maintenance of read/write logs)?
You may choose a topic that relates to other courses you are taking or to research projects you are involved in. Thus you might study compiler support for a recent innovation in computer architecture or database technology. Use of machine learning techniques in translation or optimization could prove useful.
As discussed in class, you might study compiler or architectural support for code obfuscation as a way of thwarting security attacks that depend on detailed knowledge of data or code layout.
You can choose a topic discussed in lecture and consider extensions or improvements. How can evaluation of data flow solutions be improved upon? If you have a solution and change the problem only slightly (perhaps adding or deleting or changing only a single node), can you map the old solution efficiently into a new solution?
You will need to pick a topic soon. Don't spend a huge amount of time deciding. Just choose something you feel comfortable with and would like to work on. You may work alone or in 2 or 3 person groups. Naturally, group projects should be more challenging and comprehensive than individual ones. Feel free to talk to the instructor, the TA or other faculty members. No later than Tuesday December 2nd hand in a one page description of what you plan to do (and perhaps are already doing!). We'll give you feedback on how reasonable your proposed project is.
On the due date, hand in to the instructor a report (either in electronic or paper form) on what you've done along with any preliminary results you have. You need not hand in a completely debugged project (though that would be nice), but you should provide enough results to allow your project to be properly evaluated. What we'll be particularly interested in is evidence that you've chosen an interesting problem, and have thought through the theoretical and practical problems involved.