[LLVMdev] Core LLVM status update

[Chris Lattner]

Hi everyone,

Here's an update on what we've been up to and how the LLVM 1.0 release is
shaping up.  Overall, things are going well, and it looks highly likely
that we'll get the release out by the end of the month!

Here's the hilights of the last few weeks:

1. John checked in support for building LLVM into multiple different
   object directories in the Autoconf style.  He also converted the
   regression test suite to use the QMtest tool (by CodeSourcery):
  http://mail.cs.uiuc.edu/pipermail/llvmdev/2003-September/000474.html

2. A new "Unwind" instruction has now been added to LLVM:
        http://llvm.cs.uiuc.edu/docs/LangRef.html#i_unwind
   This instruction, combined with the extant invoke instruction, allows
   the LLVM infrastructure to finally support exception handling and
   setjmp/longjmp.  Currently, however, the C backend is the only code
   generator which has implemented the unwind instruction.

   Note, however, that setjmp/longjmp are not currently translated into
   the right calls (but will soon, we hope).

3. The C++ front-end now has full support for C++ exceptions, mapping them
   onto the LLVM unwinding mechanisms and a runtime library.  It
   supports all of the C++ exception handling mechanisms (try, catch,
   throw, rethrow, function try block, exception specifications, terminate
   & unexpected handlers, etc), as well as the GCC "cleanup" attribute in
   C.  This means that programs using exception handling now compile and
   execute correctly, at least with the C back-end.

4. The LLVM infrastructure has improved support for programs that
   use exception handling.  In particular, the inliner can now inline
   functions which throw exceptions (turning the throw into a direct
   branch to the "catch block", as required), as well as inlining
   "invoke" instructions.  In addition, we also now have a -prune-eh pass
   which removes EH information from functions which provably cannot throw
   (which is a LOT of them).

5. The 'gccas' utility runs the inliner and EH pruner by default now, so
   small functions should be inlined as you would expect.  The inliner
   is currently tuned to not be very aggressive.  Currently it only
   inlines functions if the result will be a SMALLER program, which is
   often the case when inlining small C++ methods.

6. The LLVM infrastructure and C/C++ front-ends have been updated to
   support volatile variables.  In the LLVM representation, loads and
   stores can now be marked as being volatile (in contrast to C,
   "declarations" are not marked as volatile).  This is described here:
      http://llvm.cs.uiuc.edu/docs/LangRef.html#i_load
      http://llvm.cs.uiuc.edu/docs/LangRef.html#i_store
   The existing LLVM optimizations have been updated to honor volatile
   loads and stores.

7. Misha compiled a ton of random programs with LLVM and ran them with
   the X86 JIT (finding several bugs).  This includes GNU coreutils,
   bison, ed, gawk, gnugo, xboard, nano, gnuchess, screen, grep, sed, etc.
   We, uhh, invested some time "testing" xboard (an X windows chess
   client) to make sure it worked properly.  :)

8. Brian refactored the Interpreter and the JIT (collectively known as
   "execution engines") out of the LLI tool into their own libraries.
   This allows people to write other tools which need Execution Engines
   without having to hack LLI.  The execution engine support figures out
   the appropriate type of EE to create based on the current host (either
   one of the two JITs, or the interpreter if the JITs won't work).  He
   also dramatically simplified the interpreter by removing a bunch of
   code which was never used.

9. Misha added some performance improvements to the indirect stub
   generation facilities in the Sparc JIT.

10. John added support for 'envp' to the JIT, so we can now run programs
    like 'env' correctly in the JIT.

11. The C/C++ front-end has been updated to generate array subscripts of
    pointers in a type safe manner.  Before, GCC was lowering functions
    like this:
      int test(int *P, int K) { return P[k]; }
    to use explicit pointer arithmetic, which made the LLVM code much less
    useful (and horribly non-typesafe).  Proper getelementptr instructions
    are now produced.

11. The LLVM C/C++ front-end now properly supports weak symbols.

12. Benchmark in the test/Programs hierarchy have been reorganized into
    a directory for each suite (Olden, Ptrdist, McCat, etc)

With these changes, the only two major C and C++ features missing from
LLVM are support for setjmp/longjmp (hopefully coming soon), and support
for inline assembly (which will be added sometime after the 1.0 release).

If you have any questions or comments about LLVM, please feel free to get
in contact with us.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/