Re: [Libjit-developers] libjit vs LLVM

[Chris Lattner]

On Fri, 28 May 2004, Rhys Weatherley wrote:

> On Friday 28 May 2004 01:48 pm, Chris Lattner wrote:
> > On Fri, 28 May 2004, Rhys Weatherley wrote:
> > > I was going strictly by the documentation on your Web site.  From that
> > > documentation, it appeared that LLVM had more in common with Parrot's
> > > imcc mechanism than libjit.  I apologise if this is incorrect.
> >
> > Interesting?  Can you point out the doc that gave you this impression?  I
> > would really like to fix it.  :)
>
> http://llvm.cs.uiuc.edu/docs/LangRef.html
>
> That document is clearly describing an on-disk text representation of
> primitive instructions.  Just like imcc.  I merely assumed that I was
> required to generate the text form to use it.

Yes, LLVM does have two on-disk formats: a text representation and a
bytecode representation.  It does state pretty clearly in the intro of
that doc that there is also an in-memory compiler IR (and there is a 1 to
1 mapping between the three).  I don't see what any of this has to do with
the language-specific runtime though. :)

> Looking further into the site, there is other API documentation, but the front
> page documentation gives the impression that on-disk forms are required to
> use LLVM.  The bulk of the documentation seems concerned with generating,
> consuming, linking, and executing the LLVM bytecode form.  Bytecode forms are
> explicitly out of scope for libjit, of course.

I guess I really don't understand why it's a BAD thing to be able to
visualize the code fragments that are being executed and compiled.  You
don't have to go to the disk to JIT something at all, but it makes it
substantially easier to debug things when they go wrong.  These
capabilities do not make the subset of LLVM that is equivalent to libjit
any less powerful.

> I'm still looking for an equivalent of libjit's Tutorial 1 - i.e. building and
> compiling a function on the fly, and then executing it immediately without
> some intermediate on-disk form being generated.  Perhaps you could point me
> in the right direction?

We don't have a precanned example of how to do it in the docs, but it's
pretty simple.  There is a really easy introduction to producing the IR
though.  In this case it builds the IR then writes it out to bytecode, but
it would be just as easy to create an execution engine (JIT or
interpreter) to run it.  Here's the code for the example:
http://llvm.org/cvsweb/cvsweb.cgi/llvm/projects/ModuleMaker/tools/ModuleMaker/ModuleMaker.cpp?rev=1.2&content-type=text/x-cvsweb-markup

To JIT compile the example, you would just create an ExecutionEngine and
call the getPointerToFunction(F) method, then call through the resultant
function pointer.

> P.S. LLVM is very cool - I have nothing against it per se.  I've merely set my
> sights a little lower in the interest of VM authors.

I guess I really don't understand this attitude.  I imagine that you want
libjit to continue growing into a capable and powerful system, at which
point you will add some of the things that LLVM provides.  The alternative
is to go the direction of GNU lightning, which is a very restricted system
that is pretty hard to use for many tasks: and it certainly does not
provide performance.

I suspect that you will object to the use of C++.  If desired, it would be
easy to make C wrappers around LLVM functionality.  In fact, if there was
interest in such a thing, perhaps it would make sense to make the wrappers
be libjit compatible.  That seems like it could be the best of both
worlds.  That said, the C++ API is really nice to use.  :)

-Chris

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