Hi Anton, On Jun 27, 2007, at 11:07 PM, Anton Korobeynikov wrote:

Hello, Richard.

...

Generating c code in llvm backend would sort of defeat the point of it IMHO. We already have a backend that generates c. On the other hand, if we hand write the c code - it may be an neverending task of adding hacks to the backend. For instance just getting at errno is particularly problematic right now - and would involve a function call from a constant value. which means injecting a few lines assembly and a temporary variable. Easy to do, but it is nice right now that we pretty much have a direct mapping from our our lli form to llvm assembly.

^^^ ahem, "ssi form"

I've talked a little bit with Chris Lattner about this (calling C API) issue. Except stubs/wrappers it seems there are ways to call C API

1. Use more or less portable runtime, which will "unify" such calls. For example, one can use APR (HLVM, in fact, will use it)

2. Delegate stubs resolution to specialised version of lli. I think, LLVM's itself OS abstraction library (libSystem) can be partly used.

thanks for these ideas. i guess Armin has replied already. I am guess the biggest concern is how to wrap libraries outside what these support.

I personally like the second variant more. Anyway, some specialised lli variant (or some application, which will call LLVM's execution engine) will be needed, if pypy would want some extended features (like accurate GC, vectorisation, etc) from LLVM in the future.

We never managed to run pypy under lli. In was one of the early goals, but it were waiting until gc to mature in the pypy infrastructure. Since that has happened, the llvm backend hasn't had much active development. Right now it only works with boehm, and not surprisingly the interaction of llvm's jit and boehm doesn't go very well in hand. I still think it would be fun and interesting to see pypy-llvm working under lli. Cheers, Ricahrd