similar to: [LLVMdev] Backend vs JIT : GPU

Hello Developers, This is regards to my project plan. I am an engineering student and passionate about everything related to mobile, web and Compiler Design specially for embedded industry. I have experience of C/C++ language, developing GPU programming using OpenCL and shader language in Unix OS. I want to work on tools to make GPU computing available more simply, such as transparent LLVM

Hi everyone, I have rhel 6.x 64-bit machine and I want to install llvm-3.3. clang-3.3. Can anyone share the download link for the rhel-6 compatible (rpm package)? Regards, Gopal -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131209/20717fab/attachment.html>

Hi, This is to announce the availability of libclc, an open source, BSD licensed implementation of the library requirements of the OpenCL C programming language, as specified by the OpenCL 1.1 Specification. libclc is intended to be used with Clang's OpenCL frontend. libclc website: http://www.pcc.me.uk/~peter/libclc/ libclc is designed to be portable and extensible. To this end, it

Hey guys, This is the final list of the new maintainers of each plugin. We need two more things to do: First please the owners of the repos add the rest of the maintainers. Second I will add a note on each rails/plugin mentioning this repos updates. So from now on, if someone else is interested in helping/contributing please send a message to the appropriate repo owner. verification

Hi everybody, the compiler design lab at Saarland University (chair of Sebastian Hack) is also working on an LLVM-based OpenCL driver. The project started as a use-case for our "Whole-Function Vectorization" library, which allows to transform a function to compute the same as W executions of the original code by using SIMD instructions (W = 4 for SSE/AltiVec, 8 for AVX). The

Do we have a list of these open-source LLVM-based OpenCL projects somewhere? Off the top of my head, we have: libclc: http://www.pcc.me.uk/~peter/libclc/ pocl: https://launchpad.net/pocl clover: http://cgit.freedesktop.org/~steckdenis/clover/ (I think that all of these have BSD- or MIT-style licenses). Are there any others? -Hal On Wed, 2011-10-19 at 14:47 +0100, Peter Collingbourne wrote:

Ralf, What version of the SDK were you using for your analysis? I don't see that in the slides/pdf. Thanks, Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Ralf Karrenberg > Sent: Wednesday, October 19, 2011 2:13 PM > To: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] ANN: libclc (OpenCL C

Hi Micah, The numbers from the paper were measured with the ATI Stream SDK v2.1 (it's only mentioned in the references I think). The most recent measurements I have were done with the current v2.5. Best, Ralf Am 19.10.2011 23:43, schrieb Villmow, Micah: > Ralf, > What version of the SDK were you using for your analysis? I don't see that in the slides/pdf. > > Thanks, >

On 12/14/2011 02:41 PM, Justin Holewinski wrote: > I would favor calling conventions over metadata for the simple reason > that this maps more cleanly to the device model. Device and kernel > functions are represented differently in PTX, including (sometimes) the > way parameters are passed. For the record, marking the kernels with "calling conventions" instead of metadata

Hi Ralf, > The project started as a use-case for our "Whole-Function Vectorization" > library, which allows to transform a function to compute the same as W > executions of the original code by using SIMD instructions (W = 4 for > SSE/AltiVec, 8 for AVX). Quite interesting. We were planning to add "vectorization" to our passes also, but if I understood the

Hi all, >>> I would favor calling conventions over metadata for the simple >>> reason that this maps more cleanly to the device model. Device and >>> kernel functions are represented differently in PTX, including >>> (sometimes) the way parameters are passed. >> For the record, marking the kernels with "calling conventions" >> instead

2011/12/14 Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> > On 12/14/2011 02:41 PM, Justin Holewinski wrote: > >> I would favor calling conventions over metadata for the simple reason >> that this maps more cleanly to the device model. Device and kernel >> functions are represented differently in PTX, including (sometimes) the >> way parameters are passed.

From: Justin Holewinski [mailto:justin.holewinski at gmail.com] Sent: Tuesday, December 13, 2011 9:48 AM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Changes to the PTX calling conventions On Tue, Dec 13, 2011 at 11:25 AM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote: Currently, PTX has its own calling conventions where

Hi Carlos, On 10/20/11 9:54 AM, Carlos Sánchez de La Lama wrote: >> The project started as a use-case for our "Whole-Function Vectorization" >> library, which allows to transform a function to compute the same as W >> executions of the original code by using SIMD instructions (W = 4 for >> SSE/AltiVec, 8 for AVX). > > Quite interesting. We were planning to

Dear Justin, I am trying to add the support for some OpenCL builtin functions to the PTX backend. The attached file represent the first stub of a patch for the fmax builtin function. The test case I am trying is the following: define ptx_device float @f(float %x, float %y) { entry: %z = call float @fmax(float %x, float %y) ret float %z } declare float @fmax(float, float) But at the moment

On Tue, Dec 13, 2011 at 12:54 PM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > ** ** > > ** ** > > *From:* Justin Holewinski [mailto:justin.holewinski at gmail.com] > *Sent:* Tuesday, December 13, 2011 9:48 AM > *To:* Villmow, Micah > *Cc:* LLVM Developers Mailing List > *Subject:* Re: [LLVMdev] Changes to the PTX calling conventions**** > > ** ** >

From: Justin Holewinski [mailto:justin.holewinski at gmail.com] Sent: Tuesday, December 13, 2011 10:50 AM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Changes to the PTX calling conventions On Tue, Dec 13, 2011 at 12:54 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote: From: Justin Holewinski [mailto:justin.holewinski

Hi everybody, I am trying to produce ptx code starting from OpenCL C. I am experiencing a problem concerning pointer parameters. Here follows an example: kernel void function(__global float* parameter1) {} NVIDIA NVCC Compiler: .entry function( .param .u32 *.ptr* .global .align 4 function_param_0 ) { ret; } CLANG + LLVM PTX backend // (skipping builtin functions definitions) .entry

On 04/03/2012 03:13 PM, Hongbin Zheng wrote: > Hi Yabin, > > Instead of compile the LLVM IR to PTX asm string in a ScopPass, you > can also the improve llc/lli or create new tools to support the code > generation for Heterogeneous platforms[1], i.e. generate code for more > than one target architecture at the same time. Something like this is > not very complicated and had

Currently, PTX has its own calling conventions where they are split into kernel/device. The AMDIL backend requires very similar calling conventions and I was wondering if we could change the calling conventions from PTX_* to something more generic? Maybe just Kernel/Device? Or would it be preferable to add a new calling convention that is unique for each target, even though it duplicates