[pypy-dev] RE: LLVM backend

[Jonathan David Riehl]

On Thu, 17 Feb 2005, Carl Friedrich Bolz wrote:
> ...
> The problem is not to transform RPython to SSA since the pypy-tools do all
> the difficult work. I was talking about the implementation of Python's more
> interesting types like lists and dictionaries. All the methods of these
> types have to be implemented somehow, which I did from hand in LLVM
> assembler at first. This is what I meant when I talked about 'pain' ;-).
>
> I still have no good solution for this. At the moment I do the following:
> The methods of the list objects are implemented in C as arrays of pointers
> to "object" and turned to LLVM code (by compiling and disassembling it). The
> result is used as a kind of template: All the occurences of the pointers to
> "object" are replaced by the type of the values the list is supposed to
> hold. This sounds rather brittle but works quite well at the moment.
>
> I will probably run into limitations whith this later. For example if I
> implement exceptions (which should not be too complicated using invoke and
> unwind) I can't raise them from within the C code that produces the list
> implementation.
> ...

Previous attempts to generate C code simply have inlined the calls the
Python VM would have made.  I wonder if you aren't making things too
difficult by chosing not to leverage more of the Python C API.  In
PyFront, I wanted to use type inference to move more of the data flow
into native C types.

This model of just generating C code that does what the Python VM would
have done has other benefits.  Namely, the exception handling was simple,
even if it was done in a brute force fashion.  Each Python C API call was
checked for an exception and goto's were used to goto exception handling
code when NULL was returned.

Anyway, I look forward to looking at what's new here, and hopefully have
another RPython straw man (and implementation) to pitch at the PyCon
sprint.

-Jon