[LLVMdev] Core LLVM status update

[Chris Lattner]

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/