[pypy-dev] Fwd: Work plan for PyPy
rxe at ukshells.co.uk
Wed Jun 27 22:55:13 CEST 2007
waaaah - forget to cc everyone :-(
Begin forwarded message:
> From: Richard Emslie <rxe at ukshells.co.uk>
> Date: June 27, 2007 10:56:39 AM PDT
> To: Armin Rigo <arigo at tunes.org>
> Subject: Re: [pypy-dev] Work plan for PyPy
> Hi Armin!
> On Jun 27, 2007, at 4:40 AM, Armin Rigo wrote:
>> Hi Richard,
>> On Mon, Jun 25, 2007 at 01:01:35PM -0700, Richard Emslie wrote:
>>>> Just a sidenote - rffi supports (and uses) macros. Not sure how
>>>> will look like in a ctypes-based solution.
>>> if you are talking c macros - this could be very problematic for the
>>> llvm backend.
>> Anton (which I add to the CC's of this mail) proposed a solution for
>> calling C APIs from llvm bytecode in a portable way, which would work
>> for functions whose argument types are not exactly specified by the
>> standards as well as for some kind of macros. The idea is to
>> stub "helper" functions in C and compile them with llvm-gcc. The
>> bytecode that genllvm produces would then call the helper functions
>> instead of calling directly the external C API. Shouldn't be a
>> performance problem as llvm will inline the helpers agressively.
> ok, that is somewhat what we have now - except the stub functions
> are high level and shared *somewhat* with genc.
> 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.
>> Of course, it points again to the question of whether it's really
>> worthwhile to have an llvm backend in PyPy or if just producing C and
>> using llvm-gcc on everything wouldn't work just as well. On the
>> hand, it's interesting to note that there are other reasons for which
>> exactly the same kind of helper functions would be useful; for
>> to wrap a C library full of macros and unspecified types and
>> ctypes alone is not enough.
> Like you say, llvm-gcc (well at least v4) would probably produce
> equivalent results with genc. The way we are using llvm right now
> (as a static compiler) i'm not sure of its worthiness either of
> keeping the backend alive. Other than the potential of accurate
> gc, potential of jit (which is sort of orthogonal to this),
> potential of producing vectorized code from rpython...
More information about the Pypy-dev