similar to: [LLVMdev] Python bindings?

> Note that C bindings have been introduced since 2005, so there may be > a different route available than was taken then. Look in include/llvm- > c. The intent of the C bindings is to enable high-level language > bindings. The current focus is on enabling front-end compilers. Ocaml > and Haskell bindings have been developed atop them, the former being > in the LLVM source

On Fri, Mar 28, 2008 at 12:00 AM, Mahadevan R <mdevan.foobar at gmail.com> wrote: > 1) > Are the C bindings complete? That is, is there some part of the C++ API > that is not exposed by the C API? Nope, there's still a lot that's not done. Patches are always welcome :) We've got enough in subversion to implement the Kaleidoscope tutorial though. > 2) > Do

On Mar 26, 2008, at 06:39, Mahadevan R wrote: > Are there Python bindings for LLVM? I'm not aware of any. The PyPy compiler pipes LLVM assembly to llc rather than building the C++ IR in memory. > Apparently there was one ~2005; has this been updated since? Is > anyone working on this? > > Is the LLVM dev community interested in this? Yes! Note that C bindings have been

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

Hi all, 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 your comments. [Needless to say, it's all work in progress, but mostly it

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)

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

> Date: Sat, 22 Nov 2008 11:42:49 -0800 > From: Chris Lattner <clattner at apple.com> > Subject: Re: [LLVMdev] [ANN] llvm-py 0.5 released. > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Message-ID: <B7A557A7-587A-478A-AB94-B03FDA6254A8 at apple.com> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On Nov 22,

Hi. Version 0.5 of llvm-py, Python bindings for LLVM, has been released. This version supports (only) LLVM 2.4. New instructions of LLVM 2.4 (vicmp, vfcmp, insertvalue, extractvalue) are available. Home page: http://mdevan.nfshost.com/llvm-py/ Feedback welcome. Thanks & Regards, -Mahadevan.

Hi, While playing around on the LLVM, I tried this code: int sum(int n) { if (n == 0) return 0; else return n + sum(n-1); } and this is what "llvm-gcc -O2" gave me: define i32 @sum(i32 %n) nounwind { entry: %tmp215 = icmp eq i32 %n, 0 ; <i1> [#uses=1] br i1 %tmp215, label %bb10, label %tailrecurse.bb10_crit_edge tailrecurse.bb10_crit_edge: ; preds =

On Tue, Jun 10, 2008 at 11:07 PM, Mahadevan R <mdevan.foobar at gmail.com> wrote: > int sum(int n) > { > return n + sum(n-1); > } > > it generates this: > > define i32 @sum(i32 %n) nounwind { > entry: > %tmp2 = add i32 %n, -1 ; <i32> [#uses=1] > %tmp3 = tail call i32 @sum( i32 %tmp2 ) nounwind ; <i32>

Hi, The LLVM Assembly Language Reference [1] incorrectly states that the prefix used for dll{import,export} is _imp__; it is actually __imp_. The attached patch fixes this. Thanks & Regards, -Mahadevan. [1] file:///home/mdevan/llvm/docs/LangRef.html#linkage -------------- next part -------------- A non-text attachment was scrubbed... Name: doc-dllimport-prefix.patch Type: text/x-diff Size:

On Tue, Jul 8, 2008 at 12:00 AM, Chris Lattner <sabre at nondot.org> wrote: > On Mon, 7 Jul 2008, Mahadevan R wrote: >> While going through the list of intrinsics in Intrinsics.td, I found >> that it does not match the list given in Language Reference [1]. Does >> this mean that they are not to be used / don't work? Or is it just >> that the documentation is

> From: OvermindDL1 <overminddl1 at gmail.com> > There could just as easily be language bindings between C++ and > Python, he chose the C bindings probably just because they were > easier, but they are most certainly not required. I know that is the > case in a few other scripting languages as well. He ( I :-) ) chose llvm-c based on the thread starting here:

On Fri, May 16, 2008 at 12:31 PM, Duncan Sands <baldrick at free.fr> wrote: >> > If this is an arbitrary struct, it can be quite tricky. Do you have >> > to worry about bitfields and variable sized fields (for example a >> > variable length array at the end)? What about unions? >> >> There are no bitfields, but it does have a variable length array at

Hi, On Sun, Aug 3, 2008 at 11:42 PM, Chris Lattner <clattner at apple.com> wrote: > > On Aug 3, 2008, at 7:54 AM, Mahadevan R wrote: > >> Hi, >> >> Just wondering -- shouldn't all (C linkage) functions exposed by >> LLVM-C (and written in C++) be catching std::exception (or "...") to >> prevent exceptions being passed on to C callers?

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

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

Hi, Just wondering -- shouldn't all (C linkage) functions exposed by LLVM-C (and written in C++) be catching std::exception (or "...") to prevent exceptions being passed on to C callers? [OT: Does clang warn about throw statements from within "extern C" functions?] Thanks & Regards, -Mahadevan.

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. > >>