similar to: [LLVMdev] Portable Computing Language (pocl) v0.8 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 need for target-dependent manual optimizations. At the core of pocl is the

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

> From: "Dimitri Tcaciuc" <[hidden email]> > Sent: Sunday, January 27, 2013 3:42:42 AM > Subject: [LLVMdev] SIMD trigonometry/logarithms? > > I was looking at loop vectorizer code and wondered if there was any > current or planned effort to introduce SIMD implementations of > sin/cos/exp/log intrinsics (in particular for x86-64 backend)? I am currently

The lack of an open-source vector math library (which is what you suggest here) prompted me to start a project "vecmathlib", available at < https://bitbucket.org/eschnett/vecmathlib>. This library provides almost all math functions available in libm, implemented in a vectorised manner, i.e. suitable for SSE2/AVX/MIC/PTX etc. In its current state the library has rough edges, e.g.

I am tracking down an x86-64 code generation problem that has to do with AVX instructions. The symptom is: a function is called, and the upper half of the function argument (which is short16) is zero. This happens only when I compile code with pocl, but not when I use clang and/or llc manually. I tracked this down to the following. The call site looks like vmovdqa 24064(%rsp), %ymm0 vmovdqa

Pocl is a portable open source (MIT-licensed) implementation of the OpenCL standard (1.2 with some 2.0 features supported). In addition to producing an easily portable open-source OpenCL implementation, another major goal of this project is improving performance portability of OpenCL programs with the kernel compiler and the task runtime, reducing the need for target-dependent manual

What would be ideal is to have the alloca instruction be able to allocate memory indifferent address spaces instead of only being in private. Micah > -----Original Message----- > From: Pekka Jääskeläinen [mailto:pekka.jaaskelainen at tut.fi] > Sent: Friday, September 28, 2012 1:17 PM > To: James Molloy > Cc: Villmow, Micah; Carlos Sánchez de La Lama; Ouriel, Boaz; pocl- > devel

Maybe it would be easier to provide a bitcode example of this problem. After thinking about this more, I'm not sure if this is applicable to SPIR itself. For you to have a constant GEP expression, you have to know the pointer size in order to correctly generate the expression. Since the pointer size itself is not known, I don't yet see how you can generate a constant expression that is

Micah, You're saying it works for you, but Clang doesn't currently anywhere near the range of horrible constantexpr constructs it is possible to create. You can "get by" at the moment with just handling ConstantGEPs, because of the way Clang works. But SPIR isn't restricted to Clang, and the problem is that it is *possible* (although not probable, or nice, but that is

Hi guys, > So it is valid SPIR, as the specification stands, to manipulate __local > variables as Constants in a way that is extremely difficult to undo. That > is, in order to transform SPIR to code that can run on a CPU, the > GlobalVariable (which is a subclass of Constant) must be replaced with a > dynamically calculated Value (which is not a subclass of constant). What about

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

I'm happy with any representation that works for optimizer. I can prepare a patch for clang to update the 'omp simd' and 'clang loop' CodeGen. We do not use LoopInfo in front-end, but it's no problem to go to the block's single predecessor and attach the metadata there. Regards, Alexander -----Original Message----- From: Tobias Grosser [mailto:tobias at grosser.es]

On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter <schnetter at cct.lsu.edu>wrote: > On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com> wrote: > >> | LLVM does not currently have special lowering handling for round(), and >> I'll propose a patch to add that, but the larger question is this: should >> fast-math change the tie-breaking

----- Original Message ----- > > On Fri, Jun 21, 2013 at 5:11 PM, Erik Schnetter < > schnetter at cct.lsu.edu > wrote: > > > > > > > On Fri, Jun 21, 2013 at 7:54 AM, David Tweed < david.tweed at arm.com > > wrote: > > > > > > > | LLVM does not currently have special lowering handling for round(), > | and >

On 09/28/2012 07:45 PM, James Molloy wrote: > That would be a simple, reasonable restriction that would stop potentially > maliciously horrible test cases causing all CPU SPIR clients to write upwards of > a hundred lines of conversion code. Are you proposing to disallow the use of an IR instruction type to *possibly* avoid problems from the (slight) misuse of another LLVM IR construct?

Yes, it would. But I was concerned Micah was just going to write it off as an implementation detail, so I felt that I should offer a "less correct but less work" option for him to consider. Cheers, James On 29 September 2012 03:16, Owen Anderson <resistor at mac.com> wrote: > > On Sep 28, 2012, at 9:45 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > >

On Sep 28, 2012, at 9:45 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > You can easily simplify this problem with a restriction in SPIR: disallow ConstantExpr casts - no ptrtoint constant expression. Because GlobalVariables have pointer type, if you disallow converting their type to non-pointer type in a constantexpr, the number of constantexpr subclasses you have to deal with is

On 2013-08-07, at 18:55 , Matt Arsenault <Matthew.Arsenault at amd.com> wrote: > On 08/07/2013 03:52 PM, Michele Scandale wrote: >> >> In the opencl specification is said that the four address spaces are disjoint, so my conclusion of non aliasing with the others. > In OpenCL 2.0, you can cast between the generic address space and global/local/private, so there's also

On Fri, Jun 21, 2013 at 7:54 AM, David Tweed <david.tweed at arm.com> wrote: > | LLVM does not currently have special lowering handling for round(), and > I'll propose a patch to add that, but the larger question is this: should > fast-math change the tie-breaking behavior of > | rint/nearbyint/round, etc. and, if so, should we make a specific effort > to > have all

Hi Justin, gentlemen, I'm afraid I have to escalate this issue at this point. Since it was discussed for the first time last summer, it was sufficient for us for a while to have lowering of math calls into intrinsics disabled at DragonEgg level, and link them against CUDA math functions at LLVM IR level. Now I can say: this is not sufficient any longer, and we need NVPTX backend to deal with