similar to: Portable Computing Language (pocl) v1.1 released

TTA-based Co-design Environment (TCE) is a toolset for design and programming of low power customized processors based on the Transport Triggered Architecture (TTA). The toolset provides a complete retargetable co-design flow from high-level language programs down to synthesizable processor RTL (VHDL and Verilog generation supported) and parallel program binaries. Processor customization points

TTA-based Co-design Environment (TCE) is a toolset for design and programming of low power customized processors based on the Transport Triggered Architecture (TTA). The toolset provides a complete retargetable co-design flow from high-level language programs down to synthesizable processor RTL (VHDL and Verilog generation supported) and parallel program binaries. Processor customization points

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

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

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

Portable Computing Language (pocl) v0.8 released Pocl's goal is to become an efficient open source (MIT-licensed) implementation of the OpenCL 1.2 (and soon OpenCL 2.0) standard. 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 compiler optimizations, reducing the

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

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

It is my view that this is an implementation detail and not an issue with the SPIR spec. As SPIR is just a representation of a program in a portable manner, it is up to the consumer of SPIR to correctly set up the kernels based on the devices calling convention/ABI when the SPIR binary is loaded for that specific device. From: mankeyrabbit at gmail.com [mailto:mankeyrabbit at gmail.com] On

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

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: > >

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

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?

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

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

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

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