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/
