similar to: [LLVMdev] llvm-py 0.5 released.

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,

Now that icmp and fcmp have supported returning vectors of i1 for a while, I think it's time to remove the vicmp and vfcmp instructions from LLVM. The good news is that we've never shipped a release that included them so we won't be providing auto-upgrade support. There is some existing backend support for vicmp and vfcmp that looks different from what icmp and fcmp do. If this

Hi. The attached patch adds wrappers for the instructions vicmp, vfcmp, ret (multiple) and getresult, and for the vicmp and vfcmp operations on constants, to llvm-c. Also: 1) There appears to be no way to create intrinsics via llvm-c. Is there? 2) The "extractvalue"[1] and "insertvalue"[2] instructions don't seem to be addable via IRBuilder. Why? Cheers, -Mahadevan.

On Jun 26, 2008, at 1:56 PM, Stefanus Du Toit wrote: > Hi, > > I have some questions as to the definition of various vector > instructions. In particular, I believe there are some gaps and > inconsistencies in the vector instructions, and I'm interested in > hearing whether you agree that these should be improved or whether > there are other ways to solve these problems.

On Dec 25, 2008, at 11:02 AM, Eli Friedman wrote: > On Thu, Dec 25, 2008 at 1:54 AM, Eli Friedman > <eli.friedman at gmail.com> wrote: >> On Thu, Dec 25, 2008 at 1:28 AM, Claudio Basile <cbasile at tempo- >> da.com> wrote: >>> Hi all, >>> >>> is there any way to compare two 128bit values? >>> I have tried 3 different approaches

On Thu, Dec 25, 2008 at 1:54 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Dec 25, 2008 at 1:28 AM, Claudio Basile <cbasile at tempo-da.com> wrote: >> Hi all, >> >> is there any way to compare two 128bit values? >> I have tried 3 different approaches and they all fail with an internal >> assertion. >> I'm running llvm 2.4 on

Hello All, llvm-py 0.2 has been released. IR, execution engine, and (some) passes are now covered. There is also a much better website; code is now hosted on google code. Visit http://mdevan.nfshost.com/llvm-py/index.html for more details. Thanks & Regards, -Mahadevan.

Hi. Version 0.3 of llvm-py, Python bindings for LLVM, has been released. llvm-py now supports reading/writing of bitcode and LLVM assembly files, intrinsics and all the transformation passes. Also included are bug fixes and documentation/test updates. Home page: http://mdevan.nfshost.com/llvm-py/ Thanks & Regards, -Mahadevan.

Hi. Version 0.4 of llvm-py, Python bindings for LLVM, has been released. A few bug fixes, new APIs and code cleanup have gone in for this version. This will be the last release of llvm-py based on LLVM 2.3. Next version (0.5) will be based on LLVM 2.4 and will not be compatible with LLVM 2.3. I hope to release 0.5 very soon. Home page: http://mdevan.nfshost.com/llvm-py/ Thanks & Regards,

Hi Dan, Thanks for your comments. I've responded inline below. On 26-Jun-08, at 6:49 PM, Dan Gohman wrote: > On Jun 26, 2008, at 1:56 PM, Stefanus Du Toit wrote: >> >> === >> 1. Shufflevector only accepts vectors of the same type >> >> I would propose to change the syntax from: >> >>> <result> = shufflevector <n x <ty>>

On Jul 21, 2008, at 1:21 PM, Stefanus Du Toit wrote: > Hi, > > We would like to extend the vector operations in llvm a bit. We're > hoping to get some feedback on the right way to go, or some starting > points. I had previously had some discussion on this list about a > subset of the changes we have in mind. > > All of these changes are intended to make

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

On Thu, Dec 25, 2008 at 1:28 AM, Claudio Basile <cbasile at tempo-da.com> wrote: > Hi all, > > is there any way to compare two 128bit values? > I have tried 3 different approaches and they all fail with an internal > assertion. > I'm running llvm 2.4 on x86 with the following command line: > > > llvm-as test.ll -o test.bc > > llc test.bc -filetype=asm

Hi, I have some questions as to the definition of various vector instructions. In particular, I believe there are some gaps and inconsistencies in the vector instructions, and I'm interested in hearing whether you agree that these should be improved or whether there are other ways to solve these problems. === 1. Shufflevector only accepts vectors of the same type Shufflevector seems overly

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 Jun 27, 2008, at 8:02 AM, Stefanus Du Toit wrote: >>>> <result> = shufflevector <a x <ty>> <v1>, <b x <ty>> <v2>, <d x >>>> i32> >>>> <mask> ; yields <d x <ty>> >>> >>> With the requirement that the entries in the (still constant) mask >>> are >>> within

On Mon, Jul 21, 2008 at 1:21 PM, Stefanus Du Toit <stefanus.dutoit at rapidmind.com> wrote: > 1) Vector shl, lshr, ashr > > I think these are no-brainers. We would like to extend the semantics > of the shifting instructions to naturally apply to vectors as well. > One issue is that these operations often only support a single shift > amount for an entire vector. I assume it

On Monday 21 July 2008 15:21, Stefanus Du Toit wrote: > We would like to extend the vector operations in llvm a bit. We're > hoping to get some feedback on the right way to go, or some starting > points. I had previously had some discussion on this list about a > subset of the changes we have in mind. Woohoo! We've been interested in talking about this for some time. >

Hi, We would like to extend the vector operations in llvm a bit. We're hoping to get some feedback on the right way to go, or some starting points. I had previously had some discussion on this list about a subset of the changes we have in mind. All of these changes are intended to make target-independent IR (i.e. IR without machine specific intrinsics) generate better code or be