| blob | bc574e53434c0c7724d33c390e85df6582c3c49a |
3 <html>
4 <head>
7 </head>
8 <body>
11 Open LLVM Projects
12 </div>
14 <ul>
17 <ol>
24 </ol></li>
27 <ol>
34 </ol></li>
35 </ul>
39 </div>
42 <!-- *********************************************************************** -->
45 </div>
46 <!-- *********************************************************************** -->
51 project in this document is something that would be useful for LLVM to have, and
52 would also be a great way to get familiar with the system. Some of these
53 projects are small and self-contained, which may be implemented in a couple of
54 days, others are larger. Several of these projects may lead to interesting
55 research projects in their own right. In any case, we welcome all
56 contributions.</p>
58 <p>If you are thinking about tackling one of these projects, please send a mail
60 Developer's</a> mailing list, so that we know the project is being worked on.
61 Additionally this is a good way to get more information about a specific project
62 or to suggest other projects to add to this page.
63 </p>
65 <p>The projects in this page are open-ended. More specific projects are
67 LLVM bug tracker</a>. See the <a href="http://llvm.cs.uiuc.edu/bugs/buglist.cgi?keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=enhancement&emailassigned_to1=1&emailtype1=substring&email1=unassigned">list of currently outstanding issues</a> if you wish to help improve LLVM.</p>
69 </div>
71 <!-- *********************************************************************** -->
74 </div>
75 <!-- *********************************************************************** -->
79 <p>Improvements to the current infrastructure are always very welcome and tend
80 to be fairly straight-forward to implement. Here are some of the key areas that
81 can use improvement...</p>
83 </div>
85 <!-- ======================================================================= -->
88 </div>
92 <p>
94 has <a
95 href="http://llvm.cs.uiuc.edu/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=code-cleanup&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=">"code-cleanup" bugs</a> filed in it. Taking one of these and fixing it is a good
96 way to get your feet wet in the LLVM code and discover how some of its components
97 work.
98 </p>
100 </div>
102 <!-- ======================================================================= -->
105 </div>
112 variety of interprocedural algorithms to be much more effective in the face of
113 library calls. The most important pieces to port are things like the string
117 </div>
119 <!-- ======================================================================= -->
122 </div>
126 <p>We are always looking for new testcases and benchmarks for use with LLVM. In
127 particular, it is useful to try compiling your favorite C source code with LLVM.
128 If it doesn't compile, try to figure out why or report it to the <a
130 get the program to compile, it would be extremely useful to convert the build
131 system to be compatible with the LLVM Programs testsuite so that we can check it
132 into CVS and the automated tester can use it to track progress of the
133 compiler.</p>
135 <p>When testing a code, try running it with a variety of optimizations, and with
136 all the back-ends: CBE, llc, and lli.</p>
138 </div>
140 <!-- ======================================================================= -->
143 </div>
147 <ol>
150 has a good survey of the prefetching capabilities of a variety of modern
151 processors.</li>
153 </ol>
155 </div>
157 <!-- ======================================================================= -->
160 </div>
164 <ol>
167 where LLVM code generators do not produce optimal code or simply where another
168 compiler produces better code. Try to minimize the test case that
169 demonstrates the issue. Then, either <a
172 even better, see if you can improve the code generator and submit a
173 patch.</li>
174 </ol>
176 </div>
178 <!-- ======================================================================= -->
181 </div>
185 <ol>
188 <li>Some transformations and analyses only work on reducible flow graphs. It
189 would be nice to have a transformation which could be "required" by these passes
190 which makes irreducible graphs reducible. This can easily be accomplished
191 through code duplication. See <a
197 </ol>
199 </div>
201 <!-- *********************************************************************** -->
204 </div>
205 <!-- *********************************************************************** -->
209 <p>Sometimes creating new things is more fun than improving existing things.
210 These projects tend to be more involved and perhaps require more work, but can
211 also be very rewarding.</p>
213 </div>
216 <!-- ======================================================================= -->
219 </div>
224 href="http://llvm.cs.uiuc.edu/bugs/buglist.cgi?short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=new-feature&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&namedcmd=All+PRs&newqueryname=&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=">search for bugs with a "new-feature" keyword</a>.</p>
226 </div>
228 <!-- ======================================================================= -->
231 </div>
236 both pointer analysis based optimizations as well as pointer analyses
237 themselves. It seems natural to want to take advantage of this...</p>
239 <ol>
241 - Pick one of the somewhat efficient algorithms, but strive for maximum
242 precision</li>
245 - Just an efficient local algorithm perhaps?</li>
247 <li>Implement alias-analysis-based optimizations:
248 <ul>
250 </ul></li>
251 </ol>
253 </div>
255 <!-- ======================================================================= -->
258 </div>
262 <p>We now have a unified infrastructure for writing profile-guided
263 transformations, which will work either at offline-compile-time or in the JIT,
264 but we don't have many transformations. We would welcome new profile-guided
265 transformations as well as improvements to the current profiling system.
266 </p>
270 <ol>
276 </ol>
280 <ol>
281 <li>The current block and edge profiling code that gets inserted is very simple
282 and inefficient. Through the use of control-dependence information, many fewer
283 counters could be inserted into the code. Also, if the execution count of a
284 loop is known to be a compile-time or runtime constant, all of the counters in
285 the loop could be avoided.</li>
288 piece of code an make educated guesses about the relative execution frequencies
289 of various parts of the code.</li>
291 <li>You could add path profiling support, or adapt the existing LLVM path
292 profiling code to work with the generic profiling interfaces.</li>
293 </ol>
295 </div>
297 <!-- ======================================================================= -->
300 </div>
304 <ol>
306 powerful and simple Partial Redundancy Elimination algorithm for SSA form</li>
308 - Design some way to represent and query dep analysis</li>
311 </ol>
313 </div>
315 <!-- ======================================================================= -->
318 </div>
322 <ol>
325 lower-switches pass.</li>
326 <li>Implement interprocedural register allocation. The CallGraphSCCPass can be
327 used to implement a bottom-up analysis that will determine the *actual*
328 registers clobbered by a function. Use the pass to fine tune register usage
329 in callers based on *actual* registers used by the callee.</li>
330 </ol>
332 </div>
334 <!-- ======================================================================= -->
337 </div>
341 <ol>
343 Scheme compiler, from Manuel Serrano at INRIA Sophia-Antipolis, to
344 output LLVM bytecode. It seems that it can already output .NET
345 bytecode, JVM bytecode, and C, so LLVM would ostensibly be another good
346 candidate.</li>
348 directly use LLVM C++ classes from within a compiler rather than use
349 C-based wrapper functions a la llvm-gcc. One possible starting point is the <a
354 <li>Write a disassembler for machine code that would use TableGen to output
356 <li>Random test vector generator: Use a C grammar to generate random C code;
357 run it through llvm-gcc, then run a random set of passes on it using opt.
358 Try to crash opt. When opt crashes, use bugpoint to reduce the test case and
359 mail the result to yourself. Repeat ad infinitum.</li>
361 <li>Improve the usefulness and utility of the Skeleton target backend:
362 <ul>
363 <li>Convert the non-functional Skeleton target to become an abstract machine
364 target (choose some simple instructions, a register set, etc). This will
365 become a much more useful example of a backend since it would be a simple
367 MMIX, <a
369 or come up with your own!</li>
370 <li>Use the new Skeleton backend in the Interpreter: compile LLVM to Skeleton
371 target, and then interpret that code instead of LLVM. Performance win would
372 be the primary goal, as the number of registers would be a small constant
373 instead of unbounded, for example.</li>
374 </ul></li>
375 </ol>
377 </div>
379 <!-- *********************************************************************** -->
381 <hr>
382 <address>
390 Last modified: $Date$
391 </address>
393 </body>
394 </html>