similar to: [LLVMdev] Python bindings available.

On May 10, 2008, at 05:44, Mahadevan R wrote: > I'd like to announce the availability of Python bindings for LLVM. > > It is built over llvm-c, and currently exposes enough APIs to build an > in-memory IR (and dump it!). It needs LLVM 2.3 latest and Python 2.5 > (2.4 should be sufficient, but I haven't tested). Tested only on > Linux/i386. > > Would love to hear

On 2008-05-13, at 02:12, Mahadevan R wrote: >>> That's not how the object works... > > Gordon, I think I can make it work if we have the following additional > function in LLVM-C: > > LLVMModuleRef LLVMGetModule(LLVMModuleProviderRef MP) { > return wrap(unwrap(MP)->getModule()); > } Can I ask, how general is your solution? I only intended to use this

> Consider the case where a function creates and populates a Module, stuffs it > in an ExistingModuleProvider for the JIT, then returns the ModuleProvider, > dropping direct reference to the Module. (ModuleProvider takes ownership of > the Module.) I presume that your Python object is under the impression it > owns the Module; when that goes out of scope, its refcount goes to zero

On Tue, May 13, 2008 at 1:22 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On 2008-05-13, at 02:12, Mahadevan R wrote: > > >>> That's not how the object works... > > > > Gordon, I think I can make it work if we have the following additional > > function in LLVM-C: > > > > LLVMModuleRef LLVMGetModule(LLVMModuleProviderRef

On May 12, 2008, at 02:58, Mahadevan R wrote: >> Consider the case where a function creates and populates a Module, >> stuffs it in an ExistingModuleProvider for the JIT, then returns >> the ModuleProvider, dropping direct reference to the Module. >> (ModuleProvider takes ownership of the Module.) I presume that your >> Python object is under the impression

On May 10, 2008, at 05:44, Mahadevan R wrote: > I'd like to announce the availability of Python bindings for LLVM. > > It is built over llvm-c, and currently exposes enough APIs to build > an in-memory IR (and dump it!). It needs LLVM 2.3 latest and Python > 2.5 (2.4 should be sufficient, but I haven't tested). Tested only on > Linux/i386. > > Would love to

I noticed that the ocaml compilation isn't using the .opt executables if they're available. We might gain a slight optimization in ocaml compile time by optionally using them with this patch. --- autoconf/configure.ac | 18 +++++ configure | 195 ++++++++++++++++++++++++++++++++++++++++++------ 2 files changed, 188 insertions(+), 25 deletions(-) -------------- next part

--- bindings/ocaml/llvm/llvm.ml | 2 +- bindings/ocaml/llvm/llvm.mli | 2 +- bindings/ocaml/llvm/llvm_ocaml.c | 2 +- include/llvm-c/Core.h | 32 +++++++++++++++++++------------- 4 files changed, 22 insertions(+), 16 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 316a84e85ed2363551149e65a227c8e7c8192624.diff Type:

Hi Gordon, Thanks for your comments. > > Constant.string(value, dont_null_terminate) -- value is a string > > Constant.struct(consts, packed) -- a struct, consts is a list of > > other constants, packed is boolean > > I did this in Ocaml initially, but found the boolean constants pretty > confusing to read in code. I kept asking "What's that random true

On Mon, May 12, 2008 at 7:55 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On May 12, 2008, at 02:58, Mahadevan R wrote: > > >> Consider the case where a function creates and populates a Module, > >> stuffs it in an ExistingModuleProvider for the JIT, then returns > >> the ModuleProvider, dropping direct reference to the Module. > >>

On Mon, May 12, 2008 at 9:50 PM, Gordon Henriksen <gordonhenriksen at mac.com> wrote: > On May 12, 2008, at 12:00, Mahadevan R wrote: > > > 1) The MP dtor does a no-op (deletes self, but not the module it owns) > > That's not how the object works... Yes, I know ;-) I was hoping you could add a detach() or some such API for the MP...

Hm. I may misunderstand, but I'm not sure that's an improvement over the problem you're trying to solve. How about something like this? (Please forgive any accent; I don't speak snake fluently.) class Pet(object): @staticmethod def new(): # Create a 'free' pet. It can later become owned, but not to more than one owner. return

> > That's not how the object works... Gordon, I think I can make it work if we have the following additional function in LLVM-C: LLVMModuleRef LLVMGetModule(LLVMModuleProviderRef MP) { return wrap(unwrap(MP)->getModule()); } Do you think you could add that? Can I send you a patch? Thanks & Regards, -Mahadevan.

On Nov 25, 2007, at 11:49, Jon Harrop wrote: > On Sunday 25 November 2007 12:23, Gordon Henriksen wrote: > >> If ocamlc is on your path, then 'configure; make; make install' >> should install the bindings in your ocaml lib. > > Right. I hadn't noticed they were already installed after llvm "make > install" in: > > /usr/local/lib/ocaml/

On Sunday 25 November 2007 12:23, Gordon Henriksen wrote: > On 2007-11-24, at 21:58, Jon Harrop wrote: > > - Garbage collection tuned for functional programming > > http://llvm.org/docs/GarbageCollection.html > > I've been doing some interesting work on this front. Getting Lattner- > cycles to have it reviewed and integrated is probably the biggest > challenge; LLVM

Hi Erick, Thanks, this looks good. Can you please resubmit this patch, and the others, as an attachment? On Mar 4, 2008, at 03:19, Erick Tryzelaar wrote: > --- > bindings/ocaml/llvm/llvm.ml | 2 +- > bindings/ocaml/llvm/llvm.mli | 2 +- > bindings/ocaml/llvm/llvm_ocaml.c | 2 +- > include/llvm-c/Core.h | 32 ++++++++++++++++++ > +-------------

Hi all, Thought you might be interested: llvm-py 0.6 was released a couple of days back. This release is compatible with LLVM 2.7. Check it out at http://www.mdevan.org/llvm-py/. llvm-py has it's own mailing list, at http://groups.google.com/group/llvm-py. Regards, -Mahadevan. (author of llvm-py)

I'm writing a C compiler in OCaml and I've run into a small problem. I wrote the following piece of code to generate a pointer to a string constant, so I could compile C expressions of the form "const char* p = "test\n";" : let strval = const_stringz codecontext v in dump_value strval; dump_value i32_zero; const_gep strval [| i32_zero; i32_zero |] The dump statements

Hi Mahadevan, This looks very nice. Is there a good reason to maintain this outside of the LLVM source tree, or is this something you would like to see come in tree? - Daniel On Thu, Sep 2, 2010 at 10:58 PM, Mahadevan R <mdevan.foobar at gmail.com> wrote: > Hi all, > > Thought you might be interested: > > llvm-py 0.6 was released a couple of days back. This release is

> Now to compare it in detail with the much smaller program I've got and > maybe I'll figure out what's wrong with my call to > ExecutionEngine::create. That call is perfectly valid, actually. It works for me when linked with: g++ -o b b.o `llvm-config --ldflags` `llvm-config --libs engine jit` Cheers, -Mahadevan.