[llvm-announce] LLVM June Status Update
Chris Lattner
sabre at nondot.org
Wed Jun 9 14:19:09 PDT 2004
June Status Update
------------------
Hi everyone,
Since the last status update, we've had a lot of progress on various
fronts. In particular, we passed the 15,000th commit to the llvm-commits
list, we have some great new features and documentation, new people using
LLVM, and (strangely enough) the MachineBasicBlock class seems to have
received a lot of love.
At this point, I'm thinking that the LLVM 1.3 release will probably happen
in about 6 weeks (as usual, no promises), to give us a chance to improve
the documentation more, get more experience with the new GC interfaces,
and add more cool stuff before the release. Help is always appreciated!
Here is the usual quick summary of the major things that we've been up to:
High-Level Changes:
1. LLVM (including all code generators) now supports accurate garbage
collection! This means that LLVM is now a feasible target for
languages like Java and C# that depend on generational copying
collectors for decent performance.
http://llvm.cs.uiuc.edu/docs/GarbageCollection.html
2. LLVM and the C/C++ front-end now build and work correctly on Win32
under Cygwin. This includes the JIT and C backend: the only major
missing piece is the LLC static compiler, which needs to be tweaked to
emit cygwin compatible .s files (which should be easy for someone
interested in doing it).
3. LLVM now includes a simple implementation of Andersen's
interprocedural pointer analysis algorithm
4. The inliner heuristic has been improved.
5. The main LLVM web page has a new box for applications and features of
LLVM. If you have any ideas for additions, please send them in.
6. Reid wrote a new llvm-abcd tool, which is useful for digging into the
internals of LLVM bytecode files and gathering statistics about how
effective the various compression schemes are (still in development).
Documentation improvements:
7. Misha finished making all the documentation conform strictly to the
HTML4.01 standard.
8. The LLVM Alias Analysis document is updated and vastly improved:
http://llvm.cs.uiuc.edu/docs/AliasAnalysis.html
9. Reid started documenting the LLVM bytecode format:
http://llvm.cs.uiuc.edu/docs/BytecodeFormat.html
10. The LLVM code generator interfaces and implementations are finally
getting high-level documentation:
http://llvm.cs.uiuc.edu/docs/CodeGenerator.html
11. Brian is converting all of the CommandGuide documents to perl pod
files, so that we will eventually have man pages for all of the LLVM
tools.
12. ALL of the documentation is now linked off the docs page [what a
concept :)] http://llvm.cs.uiuc.edu/docs/
VM Core Changes:
13. Reid completely rewrote the LLVM SymbolTable class to separate handling
of the Type class from other Values and cleaned the whole thing up
substantially. He even added docs to the Programmer's Manual for it. :)
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20040524/014614.html
14. Alkis added constructors for all of the LLVM instruction classes,
allowing them to autoinsert at the end of a basic block.
15. LLVM is now much better at isolating all of the system-specific
routines that it uses in its libsupport library.
Code generator changes:
16. Brian added unique IDs to MachineBasicBlocks, making some clients
simpler.
17. Brian eliminated the need for the LLVM CFG to match the machine code
CFG, and added support to the MachineBasicBlock class for traversing
the CFG.
18. Tanya fixed the MachineBasicBlock class to have parent pointers (to
the MachineFunction object they are embedded into), which allowed
cleaning up a bunch of code. She also hooked up MachineBasicBlocks
into the LLVM memory leak detector like other LLVM objects.
19. X86: Substantially better code is now generated for address-exposed
automatic variables.
20. X86: Other minor code quality improvements.
21. The C backend now emits syntactic loops in the output .c file, in
order to get decent code quality from C compilers that do not handle
gotos well (like GCC).
22. Vladimir Prus contributed changes to the TargetFrameInfo class to make
it work for targets whose stack grows up as well as down in memory.
23. The TargetMachine class is now cleaner and more regular.
Miscellaneous Changes:
24. Reid added regression and feature testing to the nightly tester.
25. Tanya and Misha found and fixed all broken links on the LLVM web page.
26. Brian got the nightly tester running on a PowerPC box (C backend
only).
27. Bugpoint can now automatically narrow down miscompilations (due to
optimizations or faulty code generators) to individual basic blocks in
many cases.
28. The C front-end now produces simpler code that does not have to be
optimized as much as before, leading to faster compiles in some cases.
29. John added obsequi to the program tester.
30. The spurious "WARNING: Found global types that are not compatible"
warnings while linking C++ programs have been fixed.
31. llvmgcc now compiles with GCC 3.4 (thanks to Markus F.X.J. Oberhumer).
In addition, we've found and fixed a few more minor bugs, but nothing
critical:
C frontend: PR298, PR329, PR355
Code generator: PR337
Verifier: PR340
Stacker: PR178
As always, if you have any questions or comments about LLVM or any of the
features in this status update, please feel free to email the llvmdev
list!
Here's a link to the May status update:
http://mail.cs.uiuc.edu/pipermail/llvm-announce/2004-May/000008.html
We are always eager to hear any and all feedback (positive and negative)
about your experiences using LLVM. In particular, without your feedback
we can't make it better or fix those things that might be really bothering
you. Also, if you are interested in LLVM and want to help, but don't know
where to get started (or don't feel like you know enough to help), please
let us know. There are a ton of things to do on many different levels and
in many different areas. :)
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/
More information about the llvm-announce
mailing list