similar to: [LLVMdev] OpenCL kernel to bitcode

Displaying 20 results from an estimated 10000 matches similar to: "[LLVMdev] OpenCL kernel to bitcode"

2009 Feb 10
0
[LLVMdev] OpenCL kernel to bitcode
I don't think I ever saw a response to this message. RapidMind reported that they are using OpenCL as well as LLVM but their press release wasn't clear about whether they do this. I'd be interested in hearing from Stefanus or anyone else there about how you use OpenCL and whether it is compiled to LLVM. --Vikram Associate Professor, Computer Science University of Illinois at
2008 Nov 10
3
[LLVMdev] RapidMind/LLVM Announcement
For those curious about uses of LLVM, we just officially announced our adoption of LLVM in our products: http://www.rapidmind.com/News-Nov10-08-LLVM-OpenCL.php Thanks for all the support so far on here, we look forward to continuing to work with LLVM! -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463
2008 Nov 10
0
[LLVMdev] RapidMind/LLVM Announcement
On Nov 10, 2008, at 12:01 PM, Stefanus Du Toit wrote: > For those curious about uses of LLVM, we just officially announced our > adoption of LLVM in our products: > > http://www.rapidmind.com/News-Nov10-08-LLVM-OpenCL.php I'm thrilled to read an official announcement of that! Do you use LLVM only for static code generation or are you also doing any late (e.g.,
2009 Apr 02
2
[LLVMdev] Shuffle combine
Hi Stefanus, Thanks for verifying this. Could you patch this or should I open a new bug report and find a generic solution first? Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stefanus Du Toit Sent: woensdag 1 april 2009 18:59 To: LLVM Developers Mailing List Subject: Re: [LLVMdev] Shuffle combine On 1-Apr-09, at 12:42
2009 Apr 01
2
[LLVMdev] Shuffle combine
Hi Stefanus, Thanks for the info. I still think it's a bug though. Take for example a case where the vectors each have four elements. The values in Mask[] can range from 0 to 7, while HLSMask only has 4 elements. So LHSMask[Mask[i]] can go out of bounds, no? Cheers, Nicolas From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Stefanus Du
2009 Mar 12
2
[LLVMdev] List archives not updating
The llvm-dev archives (and other llvm/clang mailing list archives) on the web don't seem to have any new messages since some time Monday night. Stefanus -- Stefanus Du Toit <stefanus.dutoit at rapidmind.com> RapidMind Inc. phone: +1 519 885 5455 x116 -- fax: +1 519 885 1463
2009 Apr 03
0
[LLVMdev] Shuffle combine
Hi Nicolas, On 2-Apr-09, at 6:04 PM, Nicolas Capens wrote: > Thanks for verifying this. Could you patch this or should I open a > new bug report and find a generic solution first? I don't have write access so the best I could do would be to submit a patch, and I'm crazy busy at the moment. I actually think the check I described below is fine and would fix this bug (but
2009 Oct 15
0
[LLVMdev] [cfe-dev] Developer meeting videos up
On Oct 15, 2009, at 8:29 AM, Anton Korobeynikov wrote: > Hi, Chris > >> All of the videos are now up on the web page, and most of the slides >> are up (still need to get David's and Evan's slides). Please let me >> know if you hit any problems. > First of all, thanks a lot about all stuff with videos & slides > posting. > > I'm a bit curious:
2009 Apr 01
0
[LLVMdev] Shuffle combine
On 1-Apr-09, at 12:42 PM, Nicolas Capens wrote: > Hi Stefanus, > > Thanks for the info. I still think it’s a bug though. Take for > example a case where the vectors each have four elements. The values > in Mask[] can range from 0 to 7, while HLSMask only has 4 elements. > So LHSMask[Mask[i]] can go out of bounds, no? Good point! One easy way to fix this would be to use:
2009 Jun 17
4
[LLVMdev] how do I run 'make check' on say just the 'test/CodeGen' directory ?
Does 'make check' allow just running on a particualar directory of tests ? Many thanks in advance, Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090617/e0dc48e4/attachment.html>
2009 Oct 15
7
[LLVMdev] [cfe-dev] Developer meeting videos up
Hi, Chris > All of the videos are now up on the web page, and most of the slides > are up (still need to get David's and Evan's slides).  Please let me > know if you hit any problems. First of all, thanks a lot about all stuff with videos & slides posting. I'm a bit curious: is there any reason why are other slides / videos not available (it seems that the ones missing
2009 Apr 01
2
[LLVMdev] Shuffle combine
Hi all, I'm having some trouble understanding the following lines in InstructionCombining.cpp, which possibly contain a bug: if (Mask[i] >= 2*e) NewMask.push_back(2*e); else NewMask.push_back(LHSMask[Mask[i]]); When Mask[i] is bigger than the size of LHSMask it reads out of bounds on that last line. I believe the first line is there to try to prevent that but then it
2009 May 01
7
[LLVMdev] PointerIntPair causing trouble
Hi all, I've located a regression that causes my project to crash. It's in revision 67979, where PointerIntPair is changed from storing the integer in the upper bits instead of the lower bits. My project is an experimental JIT-compiler in Windows. So I was wondering if anyone had any clue why the new PointerIntPair implementation might fail. It doesn't seem very safe to me to
2009 May 02
2
[LLVMdev] PointerIntPair causing trouble
On May 1, 2009, at 3:40 PM, Stefanus Du Toit wrote: > Hi Nicolas, > > Looks like Preston and I have found the cause of the problem. The > issue is with PointerLikeTypeTraits<T*>::NumLowBitsAvailable. This > is set to 3, which basically assumes that unless the traits are > specialized for a particular pointer type, objects of that type are > allocated with
2009 Jan 30
2
[LLVMdev] Reassociating expressions involving GEPs
Hello, We've run across the following missed optimization: in the attached loop (addind.c/addind-opt.ll) there's a lookup into an array (V) using an indirect index (coming from another array, WI[k]) offset by a loop- invariant base (l). The full addressing expression can be reassociated so that we add the offset l to V's base first, and then add the indirect part. This makes
2009 Jan 30
0
[LLVMdev] Reassociating expressions involving GEPs
On Fri, Jan 30, 2009 at 3:03 PM, Stefanus Du Toit <stefanus.dutoit at rapidmind.com> wrote: > The computation of %base then becomes loop-invariant and can be lifted out. > > What's the best way to add this optimization to LLVM? Probably the best place is LICM itself... only loop transformations are aware whether something is loop-invariant. Although, I'm not completely
2008 Jul 31
5
[LLVMdev] Generating movq2dq using IRBuilder
On Jul 31, 2008, at 7:22 AM, Nicolas Capens wrote: > In the same breath I’d also like to kindly ask if someone could have > a look at the reverse operations, namely trunk from 128 to 64 bit > using movdq2q, and 128 to 32 and 64 to 32 using movd. This also > seems related to Bug 2585. Thanks again. The operations you're describing can be represented as insertelement and
2009 Mar 12
0
[LLVMdev] List archives not updating
Stefanus Du Toit wrote: > The llvm-dev archives (and other llvm/clang mailing list archives) on > the web don't seem to have any new messages since some time Monday > night. > It seems to be working for me. Does it work for you now? -- John T. > Stefanus > > -- > Stefanus Du Toit <stefanus.dutoit at rapidmind.com> > RapidMind Inc. > phone: +1
2008 Jul 31
0
[LLVMdev] Generating movq2dq using IRBuilder
On 31-Jul-08, at 2:38 PM, Dan Gohman wrote: > On Jul 31, 2008, at 7:22 AM, Nicolas Capens wrote: >> In the same breath I’d also like to kindly ask if someone could have >> a look at the reverse operations, namely trunk from 128 to 64 bit >> using movdq2q, and 128 to 32 and 64 to 32 using movd. This also >> seems related to Bug 2585. Thanks again. > > The operations
2008 Aug 01
1
[LLVMdev] Generating movq2dq using IRBuilder
Hi Stefanus, I'm not if using MMX instructions when doing operations on 64-bit vectors is so terrible? With x86-64 you have double the registers, but it comes at the cost of longer instruction encodings. So there's probably no benefit using SSE. Or am I missing something? Cheers, Nicolas -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at