similar to: [LLVMdev] Small doc fix.

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

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

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

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

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

Hi Nico, Reid, and Anton, I missed the discussion when I implemented dllexport/dllimport for our local tree. I essentially implemented your approach#1. I was trying to avoid the various external_linkage + some_attribute approaches because it seems that external_linkage would imply the external linkage without the dllimport/dllexport semantics, and there may be existing compiler codes that rely on

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

Hello, while improving and extending support for dllexport/import I have noticed that the current way these are implemented is problematic and I would like some input on how to proceed. Currently dllexport/dllimport is treated as linkage type. This conflicts with inlined functions because there is no linkage for the combination of both. On first though, combining both doesn't make sense, but

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

> 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

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

On Mon, Jul 7, 2008 at 6:41 PM, Mahadevan R <mdevan.foobar at gmail.com> wrote: > 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 >>>

> Date: Sat, 22 Nov 2008 09:30:09 -0800 > From: Nick Lewycky <nicholas at mxc.ca> > Subject: Re: [LLVMdev] [ANN] llvm-py 0.5 released. > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Message-ID: <492841A1.2040400 at mxc.ca> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Mahadevan R wrote: >> Hi. >> >>

On 23.04.2013 19:10, Gao, Yunzhong wrote: > I missed the discussion when I implemented dllexport/dllimport for our local tree. I > essentially implemented your approach#1. I was trying to avoid the various > external_linkage + some_attribute approaches because it seems that external_linkage > would imply the external linkage without the dllimport/dllexport semantics, and there > may

After a long processing, I was able to create a version of a small C# class that was able to emulate the rproxy by P/Invoke. This is mostly to find a workaround a performance problem of the StatConnector. It's almost work but ... I have strange memory exception when I call the print function. The variable seems to not survive from one call to the other. As there is no debug symbol for