[pypy-dev] Re: [LLVMdev] Re: LLVM and PyPy

[Chris Lattner]

> On Sun, Nov 02, 2003 at 10:56:34AM -0600, Chris Lattner wrote:
> > > driving LLVM from LLVM code is closer to our needs.  Is there a specific
> > > interface to do that?
> >
> > Sure, what exactly do you mean by driving LLVM code from LLVM?
>
> Writing LLVM code that contains calls to the LLVM framework's compilation
> routines.

Oh, I see.  :)

> Sorry if this is a newbie question, but are we supposed to be able to
> use all the classes like ExecutionEngine from LLVM code produced by our
> tools (as opposed to by the C++ front-end) ? Or would that be a real
> hack ? In other words, can we write a JIT in LLVM code ?

This is not something that we had considered or planned to do, but there
is no reason it shouldn't work.  LLVM compiled code follows the same ABI
as the G++ compiler, so you can even mix and match translation units or
libraries.

> I understand this is not what you have in mind for Java, for example,
> where you'd rather write the JIT *for* but not *in* LLVM code.

Well, that's sort-of true. You can ask Alkis for more details, but I think
that he's writing the Java->LLVM converter in Java, which will mean that
the converter is going to be compiled to LLVM as well.  He's doing this
work in the context of the Jikes RVM.

> In PyPy we are considering generating different versions of the
> low-level code:

> The first is a regular Python interpreter (I), similar to the general design
> of interpreters written in C.  It is the direct translation of the Python
> source code of PyPy.
>
> Now consider a clever meta-interpreter (M) that interprets (I) with as
> argument an input user program (P) in Python.  Note that we include the
> user program's runtime arguments in (P).  Using feed-back, (M) could
> specialize (I) to some partial information about (P); a typical choice
> is the user code and the type of the user variables, but in general it
> is a more dynamic part of (P).  Now consider (M) itself and specialize
> it statically for its first argument (I) for optimization.  The result
> is efficient low-level code that can dynamically instrument and compile
> any user program (P).  This efficient low-level code can also be written
> by hand; it is what I did in Psyco.  Now that I know exactly how such
> code must be written it is not difficult to actually generate it out of
> the regular Python source code of (I), i.e. PyPy.  We won't actually
> write (M).

This should be doable. :)  I've read up a little bit on Psyco, but I'm
still not sure I understand the advantage of translating a basic block at
a time.  An easier way to tackle the above problem is to use an already
supported language for the bootstrap, but I think the above should work...

-Chris

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