similar to: LLVM for OpenCL

Hi Alexey, Your reply has been a great help to me,your way of explain the different types of compilation is very detailed and easy to understand. Even so, I have a couple of questions. 1) What do yourefer by OpenCL RT? 2) Could you give me some examples of an open-source OpenCL implementation and update optimization pipeline? Thank you in advance. Regards El vie., 20 sept. 2019 a las 12:34,

Dear all, I have a couple of questions of SPIR-V implementation for OpenCL. The first one is about the tool spirv-opt from the project SPIRV-TOOLS. When you use that tool like "spirv-opt test.spv -o test.spv", it changes something at the file or it does not do anything by not using any flag? I think it is like a "No action" flag but I am not 100% sure about that. The second

Dear all, After a huge amount of time trying to install LLVM and Clang i could finally do it, so now im trying to use this tools for generating a bytecode, then apply it modular optimizations and then generate an executable to test the result. First, I only want to compile a project and execute it to see how it works, specifically this one:

> > For the record, I just workarounded it in pocl by borrowing the > BreakConstantGEPs code from SAFECode. But for SPIR specs, IMHO, this should > be reconsidered. Yes, I agree. On 24 September 2012 15:08, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi>wrote: > Well, > > To be honest I'm not very comfortable with the whole constant GEP > idea. It's a

Hi all, Another OpenCL C implementation issue I'm currently fighting with is how to best implement the automatic __local variables. Seems SPIR enforces the current Clang implementation of them that converts the automatic locals to C function static variables (thus, in practice global variables). Clearly, this is not a thread safe "final implementation", thus works as is only when

Hi, Sorry, With a prod from Silviu (cc'd) I now understand - I was interpreting your use of "constant GEP" as "GEP with constant operand" as opposed to "ConstantGEP node" which of course can only take a Constant* operand, not a Value* operand. I now fully see the problem and realise that my solution is also prone to that problem :) Cheers, James On 24

Portable OpenCL (pocl) v0.6 released ------------------------------------ Portable OpenCL aims to be an efficient open source (MIT-licensed) implementation of the OpenCL 1.2 standard. In addition to producing an easily portable open source OpenCL implementation, another major goal of the project is improving performance portability of OpenCL programs with compiler optimizations, reducing the

Micah, Boaz, Do you guys have any ideas about how to fix this issue? Cheers, James On 24 September 2012 16:04, James Molloy <james at jamesmolloy.co.uk> wrote: > For the record, I just workarounded it in pocl by borrowing the >> BreakConstantGEPs code from SAFECode. But for SPIR specs, IMHO, this >> should >> be reconsidered. > > > Yes, I agree. > >

On 09/12/2012 10:30 PM, Villmow, Micah wrote: >> case there are better ways to do that (metadata) > [Villmow, Micah] I disagree, the 'kernel' keyword specifies a different > calling convention from functions that don't have it. So we need a calling > convention that maps to that. The ABI for a kernel is different than the > ABI for a non-kernel function. The regular

Well, To be honest I'm not very comfortable with the whole constant GEP idea. It's a new thing to me and I do not fully understand its point in LLVM IR, so I probably wasn't very clear ;) Anyways, me bringing it up was meant as an example of what can happen if one (mis)uses the C function static variable semantics for something that really is a thread local variable (in usual thread

Carlos, AMD's OpenCL implementation(both CPU and GPU) has worked for years with the way SPIR represents locals. If there is problems with the representation then it is an implementation issue. One of the issues with using extra kernel arguments is that it requires extra validation and complexity at the runtime level that is not needed if it is handled internally by the compiler. That being

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

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:

Hi Ralf, On 01/31/2013 05:44 PM, Ralf Karrenberg wrote: > As for the current status, the loop vectorizer is only able to vectorize > inner loops and (I think) does not handle function calls and memory > operations well. This will prevent it from vectorizing a large group of > OpenCL kernels, and certainly all "interesting", more complex ones. Agreed -- but not being able to

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, I don't fully understand your problem description. ...is caused by LLVM/Clang thinking > they are buffers with a constant base which they eventually won't be in > a parallel WG implementation. This triggers an issue I'm currently working > on pocl: https://bugs.launchpad.net/pocl/+bug/1032203 because Clang > generates > constant GEPs for the local buffer accesses

> I am in favor of adding metadata to control different aspects of > vectorization, mainly for supporting user-level pargmas [1] but also for > DSLs. Before we start adding metadata to the IR we need to define the > semantics of the tags. "Parallel_for" is too general. We also want to control > vectorization factor, unroll factor, cost model, etc. These are used to

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

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 Pekka, hi Nadav, I didn't find the time to read this thread until now, sorry for that. I actually think you are both right :). As for the current status, the loop vectorizer is only able to vectorize inner loops and (I think) does not handle function calls and memory operations well. This will prevent it from vectorizing a large group of OpenCL kernels, and certainly all