[pypy-dev] Re: [LLVMdev] Re: LLVM and PyPy
sabre at nondot.org
Tue Nov 4 17:08:28 CET 2003
> 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
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
> 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...
More information about the Pypy-dev