It seems LLVM has gained another user, in the parrot multi language VM project. They plan to ditch their current JIT implementation and start using LLVM.
Full details are on their jit wiki planning page. There is more of a discussion on the parrot developer Andrew Whitworths blog here and here.
Parrot aligns very nicely with the LLVM project which itself is attempting to be used by many language projects.
Along with the unladen swallow project(python using LLVM for JIT), this brings other dynamic languages in contact with LLVM. This can only mean good things for dynamically typed languages on top of LLVM.
Mac ruby is another project switching to LLVM - they have been working on it since march.
Rubinius seems to be another ruby implementation mostly written in ruby, and the rest in C++ with LLVM. It even supports C API modules written for the main ruby implementation. 'Rubinius is already faster than MRI on micro-benchmarks but is often slower than MRI running applications'.
Hopefully this will help LLVM become more portable, and faster at creating code... as well as being able to create larger amounts of code(LLVM only supports generating up to 16MB of code currently, but that limit is being worked on).
It's yet to be proven that a major dynamically typed language can be sped up nicely with LLVM, but these projects using it should help it get there.
Luajit is compared to lua llvm here and here. It seems lua jit2 is faster than luallvm, and the posts explain why. It also points out that LJ2 is faster than C speeds for some things.
pypy decided not to use LLVM too, and has embarked on making their own jit system. At one point there was code in the pypy svn repository to support LLVM, but it was removed a while ago. One comment in the past was that LLVM was too slow at generating code, and that it was a very large dependency. LLVM is C++ code that takes quite a while to compile itself, and the library is quite large.
Despite these downsides of LLVM, it can generate very efficient code. LLVM is often comparable to the fastest generated code for the C language. This is one reason why the unladed swallow project has chosen it. The unladen swallow projects goal is to optimize long running server processes... so it doesn't care that much about generating fast math code, or in taking its time to generate native code. This makes sense, considering that it is a google sponsored project.
Another interesting project for python is the corepy project. It's a run time assembler for python. One project corepy is used for is to accelerate numpy operations - using SSE and multiple cores - so even the numpy written in C can go much faster with the corepy accelerated version. The numcorepy blog lists the results of the project. Including a 200,000 particle particle system done with numcorepy on the cpu(s).
In the same vein of accelerating numpy code - the pygpu, and pycuda projects make it possible to use GPU accelerated versions of numpy functions. This allows python code to run way faster than is possible on any available CPU. These projects generate shader code in C-like languages to run on the GPU. So in a way they are also JIT libraries.
liborc is a runtime cross platform assembler which supports many vector operations. Unlike many of the code generators that do not support vector operations - liborc does. It's a replacement for liboil and is used for gstreamer and dirac multimedia libraries.
Inferno is a virtual machine project which includes a JIT for many platforms.
1psyco v2 doesn't seem to have a web page yet, just a svn(not the old psyco v1 svn on source forge).
updates: from the comments... added note about mac ruby using llvm, the inferno vm, and the rubinius ruby using llvm. Added link to numcorepy project, and a link to pypy. Added some links to a comparison of lua llvm and luajit, and a link to lua llvm.