similar to: [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

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

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

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

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

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

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

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:

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:

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>

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

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

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

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

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

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

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

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

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

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