I recently realized that I haven't sent out a status update for the LLVM
core components quite a while, so here is a new one:
We've been really busy working on LLVM adding all kinds of new features,
fixing lots of bugs, and are rapidly converging on our 1.0 release for
this August. Here are some of the new features added recently:
1. Support for static constructors/destructors in programs: Static
constructors are functions which are executed before "main" is
called.
Static destructors are run after the program exits. This facility is
used by C++ frontend to run ctors/dtors of objects declared at global
scope, but can also be used by C programs (for an example, see
test/Regression/C++Frontend/ConstructorDestructorAttributes.c).
This is now supported by all backends, and recently I checked in some
optimizer improvements which allow all of the support overhead to be
dead code eliminated from programs which don't use the facilities (ie,
most C programs). This also means that the mysterious "__main"
function is finally implemented. :)
2. New transformations: We have three new transformations: dead argument
elimination, tail duplication, and scalar replacement of aggregates.
Dead argument elimination (-deadargelim) does a simple interprocedural
analysis to delete unused arguments from functions which are marked
internal. It is invoked by default by gccld and used by bugpoint.
The tail duplication (-tailduplicate) pass uses a heuristic to
eliminate unconditional branches from the program through limited code
duplication. The most important application of this pass is to
"rotate" loops so that there is two copies of the condition code
(assuming it is small enough), which means that there need not be
unconditional branches in the body of small loops. It is also good at
eliminating branches to blocks which just contain a return instruction.
It is run by gccas.
The Scalar Replacement of Aggregates (-scalarrepl) pass was made
necessary by the new C front-end, which does not do this important
optimization for us like the old one did. The pass is a
straight-forward implementation, and is run by gccas.
3. The load-vn pass was improved to implement a "store forwarding"
optimization. Basically, in a case like "store V to P; load P", it
is
capable of informing its client that the load will always produce the
value 'V'. This is enabled when the pointer analysis algorithm being
used returns must-alias information, and there are no intervening may-
aliased stores.
4. Lots of bugs have been fixed: we now have almost all of SPEC CPU2000
working (the 4 C benchmarks which don't work do not compile, they
aren't being miscompiled) with the C backend and the X86 JIT.
Additionally, Joel informed me that he recently compiled Povray through
the C-backend and it works great (we haven't tried other backends yet).
5. Brian compiled LLVM and commited changes for it to work on FreeBSD,
which was mentioned on the list.
6. There have also been the usual assortment of bugfixes and performance
improvements. In particular the Sparc backend has made good progress,
the X86 backend is a bit faster, and the C backend generates better
code.
In addition to these implemented features, we have several big projects
that are in the pipeline and nearing completion:
1. John has been busy working on our build system, converting it over to
use autoconf to configure the system and provide a framework for making
LLVM more portable.
2. John and Dinakar have been working on adding a structured
"Projects"
system to the build, which will allow people not working on the
"core" LLVM components to integrate with the LLVM build system more
easily.
3. Tanya is working on writing an 'llvm-ar' component which will speed
up
linking of static libraries in LLVM by adding support for a
table-of-contents. This will make linking programs with LLVM _much_
faster because only the .o files that are needed in our .a files will
need to be loaded (when you link a program with llvmgcc several
_large_ .a files are automatically brought in).
4. Brian has been hard at work adding the finishing touches on the static
compiler (LLC) for X86. Last I heard he had all but one benchmark
working!
5. Misha is hard at work on the Sparc JIT. It seems to be working on a
large number of benchmarks, and may be up to the level of the static
compiler soon.
Overall, LLVM is improving by leaps and bounds. We are also getting a
growing interest in LLVM from non-UIUC parties and several research groups
are interested in using it for their work.
I hope this update has been useful, I'll try to periodically send one out
to keep people up-to-date. :)
-Chris
--
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/