[LLVMdev] Re: LLVM and PyPy

[Chris Lattner]

> > Cool.  We are all big fans of Python here.  :)
>
> That's good because we might want to recode some LLVM functionalities
> in Python :-)

As long as it makes sense.  Needless duplication of effort is never a good
idea...

> > I've read up a bit on PyPy, and it looks like LLVM could be a nice way to
> > get the JIT type interface that you would like.  Also, making use of the
> > LLVM optimizer can make your staticly generated code nice and fast.  :)
>
> Yes, but we also would want to dynamically emit and execute LLVM code.
> But a static translation is indeed our first goal :-)

Of course.  We can do both.  In fact, we can even emit C code, which will
be useful initially if you're work on PowerPC machines.

> Thinking some more about it, we would probably try to translate our PyPy
> implementation into LLVM-code and also generate some glue-LLVM-code
> which allows us to programmatically drive LLVM from Python.  Is LLVM
> able to "drive" itself? I mean can the LLVM-low-level object code
> generate LLVM-low-level object code and then execute it?

Yes, this should certainly be possible.  Kindof like what the
Jalapeno/Jikes JVM does with Java.  The point about the C bindings is that
they will allow a nice interface between the parts written in python, and
the parts written in C++.  It doesn't make sense for you to rewrite all of
LLVM in python, especially since the interface to build the LLVM is pretty
clean.

> This would fit nicely with PyPy because we are running ourselves (in
> 'abstract interpretation' mode) in order to generate a low-level
> representation of ourselves.  This low-level representation is already
> close to LLVM's low-level view. So if the LLVM-code gets executed
> (beeing a python interpreter) it should be able to just-in-time-compile
> new LLVM code and execute it.  With our architecture, for such a JIT we

Makes a lot of sense.

> > At this point, we're working like crazy to get important features
> > implemented in LLVM.  We certainly acknowledge that CVS has severe
> > deficiencies, but in the near future we'll probably stay with it.
> > Perhaps after SVN 1.0 comes out... :)
>
> then we may want to mirror your cvs repo to subversion :-)

That is obviously no problem.  :)

> The reason is that we want to provide consistent versions of all
> the libraries/modules/projects we use.  And subversion makes

Makes sense.  If it is publically accessible and stable, perhaps we can
add information about it on the LLVM pages for others who would prefer to
work with SVN...

-Chris

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