similar to: [LLVMdev] LLVM bindings, scope of llvm-c

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)

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, 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 =

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.

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>

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

> 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 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, 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:

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

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

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

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

Hi, Are there Python bindings for LLVM? Apparently there was one ~2005; has this been updated since? Is anyone working on this? Is the LLVM dev community interested in this? Thanks & Regards, -Mahadevan.

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

> > 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 the end. > There are no unions. You could use llvm-gcc to convert the struct to an LLVM type.