[LLVMdev] Summer of Code

Reid Spencer reid at x10sys.com
Wed Apr 26 10:29:54 PDT 2006

On Wed, 2006-04-26 at 17:54 +0100, Ralph Corderoy wrote:
> Hi Reid,
> > If you're thinking of doing a backend, the LLVM project would probably
> > benefit more from implementing the virtual backend and its
> > Interpreter/JIT. This is a long standing project that could
> > dramatically increase the performance of the ExecutionEngine. The idea
> > is to write a backend for a virtual machine that closely matches the
> > semantics of LLVM and then implement the virtual machine. 
> I've seen this mentioned before.  What's the advantage of this over
> JITting to the host CPU ISA?  It would seem to be adding another layer
> since presumably you'd want to have JIT in the VM for the LLVM.

It doesn't make much difference to the JIT. The LLVM bytecode would be
translated (and optimized) to the native ISA as per any other backend.
That doesn't really change. The advantages are these:

1. When the program is run on a machine for which native JIT is not
available, interpretation is the only solution. Right now LLVM
interprets the LLVM IR directly. This makes it really bulky memory wise
and less than efficient. A simpler VM that had its own instruction set
could be more readily executed (basically mmap a file and start
interpreting, no bytecode unpackaging, no C++ IR to create).

2. Such a VM could store its generated VISC on disk in a readily
loadable form so that the bytecode -> executable translation need only
be done once, not on every execution.

3. the virtual ISA could become an alternative "byte code" whereby all
compilation and optimization is done ahead of time with the usual suite
of LLVM tools but the result would be runnable anywhere the VM was

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060426/56e5e245/attachment.sig>

More information about the llvm-dev mailing list