similar to: [LLVMdev] killing vicmp and vfcmp

Displaying 20 results from an estimated 700 matches similar to: "[LLVMdev] killing vicmp and vfcmp"

2009 Jun 24
1
[LLVMdev] Handling SMax(N, N - constInt) in Scalar Evolution pass
Hi all, I'm working on a project which tries to prove an access to an array is safe. For example, int foo(int s) { int * p = malloc(s * sizeof int); ... int q = p[s - 2]; } then the access of p[s - 2] always stays in bound. I implemented a prototype using the Scalar Evolution pass. Here are the pseudo-code of the implementation: const SCEV * offset =
2009 Jun 24
2
[LLVMdev] Handling SMax(N, N - constInt) in Scalar Evolution pass
On Tue, 2009-06-23 at 22:55 -0700, Nick Lewycky wrote: > Mai, Haohui wrote: > > Hi all, > > > > I'm working on a project which tries to prove an access to an array is > > safe. For example, > > > > int foo(int s) { > > int * p = malloc(s * sizeof int); > > ... > > int q = p[s - 2]; > > } > > > > then the access
2009 Jun 24
0
[LLVMdev] Handling SMax(N, N - constInt) in Scalar Evolution pass
Mai, Haohui wrote: > Hi all, > > I'm working on a project which tries to prove an access to an array is > safe. For example, > > int foo(int s) { > int * p = malloc(s * sizeof int); > ... > int q = p[s - 2]; > } > > then the access of p[s - 2] always stays in bound. > > I implemented a prototype using the Scalar Evolution pass. Here are the
2009 Jun 24
0
[LLVMdev] Handling SMax(N, N - constInt) in Scalar Evolution pass
Nick, It might be a little bit difficult to handle SMax correctly. But is it possible to reduce A+(-A) to 0 in SAddExpr? Haohui On Wed, 2009-06-24 at 01:05 -0500, Mai, Haohui wrote: > On Tue, 2009-06-23 at 22:55 -0700, Nick Lewycky wrote: > > Mai, Haohui wrote: > > > Hi all, > > > > > > I'm working on a project which tries to prove an access to an array
2009 Jun 24
1
[LLVMdev] Handling SMax(N, N - constInt) in Scalar Evolution pass
Mai, Haohui wrote: > Nick, > > It might be a little bit difficult to handle SMax correctly. But is it > possible to reduce A+(-A) to 0 in SAddExpr? Yes, it should already do that. Here's a quick test I wrote up: $ cat x.ll define i8 @test(i8 %x) { %neg = sub i8 0, %x %sum = add i8 %x, %neg ret i8 %sum } $ llvm-as < x.ll | opt -analyze
2009 Jun 25
0
[LLVMdev] killing vicmp and vfcmp
On Jun 24, 2009, at 10:02 AM, Chris Lattner wrote: > > On Jun 24, 2009, at 12:47 AM, Duncan Sands wrote: > >> Hi Nick, >> >>> Now that icmp and fcmp have supported returning vectors of i1 for a >>> while, >> >> the code generators don't know how to codegen vectors of i1, so does >> this actually work? > > No, but there are no
2009 Jun 24
3
[LLVMdev] killing vicmp and vfcmp
On Jun 24, 2009, at 12:47 AM, Duncan Sands wrote: > Hi Nick, > >> Now that icmp and fcmp have supported returning vectors of i1 for a >> while, > > the code generators don't know how to codegen vectors of i1, so does > this actually work? No, but there are no clients of them yet. -Chris
2009 Jun 24
0
[LLVMdev] killing vicmp and vfcmp
Hi Nick, > Now that icmp and fcmp have supported returning vectors of i1 for a > while, the code generators don't know how to codegen vectors of i1, so does this actually work? Ciao, Duncan.
2008 Jun 09
1
[LLVMdev] [patch] Missing instructions in llvm-c.
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.
2008 Jun 26
0
[LLVMdev] Vector instructions
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.
2008 Nov 22
2
[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.
2008 Jun 27
2
[LLVMdev] Vector instructions
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>>
2008 Jun 16
1
[LLVMdev] VFCmp failing when unordered or UnsafeFPMath on x86
Hi Chris, I've attached a replacement of fibonacci.cpp that reproduces the issue on x86/SSE systems. Regarding the definition of the VFCmp instruction, I think it would really be a lot more valuable to define it as returning all 1's or all 0's per element. Just setting the most significant bit is pretty much worthless (someone correct me if I'm wrong). I checked and I
2008 Nov 23
1
[LLVMdev] llvm-py 0.5 released.
> 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,
2008 Jul 21
0
[LLVMdev] Extending vector operations
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
2008 Jun 17
2
[LLVMdev] VFCmp failing when unordered or UnsafeFPMath on x86
Hi Nate! I don't see how that would work. Select doesn't work per element. Say we're trying to vectorize the following C++ code: if(v[0] < 0) v[0] += 1.0f; if(v[1] < 0) v[1] += 1.0f; if(v[2] < 0) v[2] += 1.0f; if(v[3] < 0) v[3] += 1.0f; With SSE assembly this would be as simple as: movaps xmm1, xmm0 // v in xmm0 cmpltps xmm1, zero // zero =
2008 Jun 13
0
[LLVMdev] VFCmp failing when unordered or UnsafeFPMath on x86
On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote: > Hi all, > > When trying to generate a VFCmp instruction when UnsafeFPMath is set > to true I get an assert “Unexpected CondCode” on my x86 system. This > also happens with UnsafeFPMath set to false and using an unordered > compare. Could someone look into this? Have you filed a bug? > > While I’m at it, is there
2008 Jun 14
0
[LLVMdev] VFCmp failing when unordered or UnsafeFPMath on x86
On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote: > Hi all, > > When trying to generate a VFCmp instruction when UnsafeFPMath is set > to true I get an assert “Unexpected CondCode” on my x86 system. This > also happens with UnsafeFPMath set to false and using an unordered > compare. Could someone look into this? Please provide a testcase. > > While I’m at it, is
2008 Jun 16
0
[LLVMdev] VFCmp failing when unordered or UnsafeFPMath on x86
On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote: > Hi all, > > When trying to generate a VFCmp instruction when UnsafeFPMath is set > to true I get an assert “Unexpected CondCode” on my x86 system. This > also happens with UnsafeFPMath set to false and using an unordered > compare. Could someone look into this? > > While I’m at it, is there any reason why only the
2008 Jun 26
2
[LLVMdev] Vector instructions
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