This document is meant to be a sort of "big TODO list" for LLVM. Each project in this document is something that would be useful for LLVM to have, and would also be a great way to get familiar with the system. Some of these projects are small and self-contained, which may be implemented in a couple of days, others are larger. Several of these projects may lead to interesting research projects in their own right. In any case, we welcome all contributions.

If you are thinking about tackling one of these projects, please send a mail to the LLVM Developer's mailing list, so that we know the project is being worked on. Additionally this is a good way to get more information about a specific project or to suggest other projects to add to this page.

The projects in this page are open-ended. More specific projects are filed as unassigned enhancements in the LLVM bug tracker. See the list of currently outstanding issues if you wish to help improve LLVM.

In addition to hacking on the main LLVM project, LLVM has several subprojects, including Clang and VMKit. If you are interested in working on these, please see their "Open projects" page:

• The Clang Open Projects list.

• The VMKit Open Projects list.

Improvements to the current infrastructure are always very welcome and tend to be fairly straight-forward to implement. Here are some of the key areas that can use improvement...

The LLVM bug tracker occasionally has "code-cleanup" bugs filed in it. Taking one of these and fixing it is a good way to get your feet wet in the LLVM code and discover how some of its components work.

Additionally, there are performance improvements in LLVM that need to get fixed. These are marked with the slow-compile keyword. Use this Bugzilla query to find them.

The llvm-test testsuite is a large collection of programs we use for nightly testing of generated code performance, compile times, correctness, etc. Having a large testsuite gives us a lot of coverage of programs and enables us to spot and improve any problem areas in the compiler.

One extremely useful task, which does not require in-depth knowledge of compilers, would be to extend our testsuite to include new programs and benchmarks. In particular, we are interested in cpu-intensive programs that have few library dependencies, produce some output that can be used for correctness testing, and that are redistributable in source form. Many different programs are suitable, for example, see this list for some potential candidates.

We are always looking for new testcases and benchmarks for use with LLVM. In particular, it is useful to try compiling your favorite C source code with LLVM. If it doesn't compile, try to figure out why or report it to the llvm-bugs list. If you get the program to compile, it would be extremely useful to convert the build system to be compatible with the LLVM Programs testsuite so that we can check it into SVN and the automated tester can use it to track progress of the compiler.

When testing a code, try running it with a variety of optimizations, and with all the back-ends: CBE, llc, and lli.

Find benchmarks either using our test results or on your own, where LLVM code generators do not produce optimal code or simply where another compiler produces better code. Try to minimize the test case that demonstrates the issue. Then, either submit a bug with your testcase and the code that LLVM produces vs. the code that it should produce, or even better, see if you can improve the code generator and submit a patch. The basic idea is that it's generally quite easy for us to fix performance problems if we know about them, but we generally don't have the resources to go finding out why performance is bad.

1. Completely rewrite bugpoint. In addition to being a mess, bugpoint suffers from a number of problems where it will "lose" a bug when reducing. It should be rewritten from scratch to solve these and other problems.
2. Add support for transactions to the PassManager for improved bugpoint.
3. Improve bugpoint to support running tests in parallel on MP machines.
4. Add JIT support to the SPARC port.

Sometimes creating new things is more fun than improving existing things. These projects tend to be more involved and perhaps require more work, but can also be very rewarding.

Add support for Type Based Alias Analysis (TBAA) to LLVM. This is not an easy or straight-forward project, but the wins can be big. For an intro to what this is and an extreme example see this presentation.

Many proposed extensions and improvements to LLVM core are awaiting design and implementation.

1. Improvements for Debug Information Generation
2. EH support for non-call exceptions
3. Add support for representing Type Based Alias Analysis (TBAA) in the LLVM IR.
4. Many ideas for feature requests are stored in LLVM bugzilla. Just search for bugs with a "new-feature" keyword.

We have a strong base for development of both pointer analysis based optimizations as well as pointer analyses themselves. It seems natural to want to take advantage of this:

1. The globals mod/ref pass basically does really simple and cheap bottom-up context sensitive alias analysis. It being simple and cheap are really important, but there are simple things that we could do to better capture the effects of functions that access pointer arguments. This can be really important for C++ methods, which spend lots of time accessing pointers off 'this'.
2. Implement support for representing language-specific Type Based Alias Analysis information in the LLVM IR.
3. The alias analysis API supports the getModRefBehavior method, which allows the implementation to give details analysis of the functions. For example, we could implement full knowledge of printf/scanf side effects, which would be useful. This feature is in place but not being used for anything right now.
4. We need some way to reason about errno. Consider a loop like this:

       for ()
         x += sqrt(loopinvariant);
   

   We'd like to transform this into:

       t = sqrt(loopinvariant);
       for ()
         x += t;
   

   This transformation is safe, because the value of errno isn't otherwise changed in the loop and the exit value of errno from the loop is the same. We currently can't do this, because sqrt clobbers errno, so it isn't "readonly" or "readnone" and we don't have a good way to model this.

   The hard part of this project is figuring out how to describe errno in the optimizer: each libc #defines errno to something different it seems. Maybe the solution is to have a __builtin_errno_addr() or something and change sys headers to use it.

5. There are lots of ways to optimize out and improve handling of memcpy/memset.
6. We need a LoopPass that replaces loops with scalar stores in them into memset/memcpy calls. This dramatically speeds up programs like 'viterbi' in the testsuite, as well as some SPEC benchmarks.

We now have a unified infrastructure for writing profile-guided transformations, which will work either at offline-compile-time or in the JIT, but we don't have many transformations. We would welcome new profile-guided transformations as well as improvements to the current profiling system.

Ideas for profile-guided transformations:

1. Superblock formation (with many optimizations)
2. Loop unrolling/peeling
3. Profile directed inlining
4. Code layout
5. ...

Improvements to the existing support:

1. The current block and edge profiling code that gets inserted is very simple and inefficient. Through the use of control-dependence information, many fewer counters could be inserted into the code. Also, if the execution count of a loop is known to be a compile-time or runtime constant, all of the counters in the loop could be avoided.
2. You could implement one of the "static profiling" algorithms which analyze a piece of code an make educated guesses about the relative execution frequencies of various parts of the code.
3. You could add path profiling support, or adapt the existing LLVM path profiling code to work with the generic profiling interfaces.

LLVM aggressively optimizes for performance, but does not yet optimize for code size. With a new ARM backend, there is increasing interest in using LLVM for embedded systems where code size is more of an issue.

Someone interested in working on implementing code compaction in LLVM might want to read this article, describing using link-time optimizations for code size optimization.

1. Implement a Loop Dependence Analysis Infrastructure
   - Design some way to represent and query dep analysis
2. Value range propagation pass
3. More fun with loops: Predictive Commoning
4. Type inference (aka. devirtualization)
5. Value assertions (also PR810).

1. Implement 'stack slot coloring' to allocate two frame indexes to the same stack offset if their live ranges don't overlap. This can reuse a bunch of analysis machinery from LiveIntervals. Making the stack smaller is good for cache use and very important on targets where loads have limited displacement like ppc, thumb, mips, sparc, etc. This should be done as a pass before prolog epilog insertion. This is now done for register allocator temporaries, but not for allocas.
2. Implement 'shrink wrapping', which is the intelligent placement of callee saved register save/restores. Right now PrologEpilogInsertion always saves every (modified) callee save reg in the prolog and restores it in the epilog. However, some paths through a function (e.g. an early exit) may not use all regs. Sinking the save down the CFG avoids useless work on these paths. Work has started on this, please inquire on llvmdev.
3. Rename ISD::BIT_CONVERT to ISD::BITCAST to match the llvm ir concept
4. Finish adapting existing targets to use the calling convention description mechanism (see lib/Target/X86/X86CallingConv.td for an example).
5. Implement interprocedural register allocation. The CallGraphSCCPass can be used to implement a bottom-up analysis that will determine the *actual* registers clobbered by a function. Use the pass to fine tune register usage in callers based on *actual* registers used by the callee.
6. Implement a verifier for codegen level instructions. To help track down malformed machineinstrs sooner and make debugging problems easier.

1. Port the Bigloo Scheme compiler, from Manuel Serrano at INRIA Sophia-Antipolis, to output LLVM bytecode. It seems that it can already output .NET bytecode, JVM bytecode, and C, so LLVM would ostensibly be another good candidate.
2. Write a new frontend for some other language (Java? OCaml? Forth?)
3. Random test vector generator: Use a C grammar to generate random C code, e.g., quest; run it through llvm-gcc, then run a random set of passes on it using opt. Try to crash opt. When opt crashes, use bugpoint to reduce the test case and post it to a website or mailing list. Repeat ad infinitum.
4. Add sandbox features to the Interpreter: catch invalid memory accesses, potentially unsafe operations (access via arbitrary memory pointer) etc.
5. Port Valgrind to use LLVM codegeneration and optimization passes instead of its own.
6. Create an LLVM pass that adds memory safety checks to code, like Valgrind does for binaries, or like mudflap does for gcc compiled code.
7. Write LLVM IR level debugger (extend Interpreter?)
8. Write an LLVM Superoptimizer. It would be interesting to take ideas from this superoptimizer for x86: paper #1 and paper #2 and adapt them to run on LLVM code.

   It would seem that operating on LLVM code would save a lot of time because its semantics are much simpler than x86. The cost of operating on LLVM is that target-specific tricks would be missed.

   The outcome would be a new LLVM pass that subsumes at least the instruction combiner, and probably a few other passes as well. Benefits would include not missing cases missed by the current combiner and also more easily adapting to changes in the LLVM IR.

   All previous superoptimizers have worked on linear sequences of code. It would seem much better to operate on small subgraphs of the program dependency graph.