search for: constantgeps

On 09/26/2012 08:21 PM, Villmow, Micah wrote: > 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. The

...he Khronos website 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<mailto: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<mailto:pekka.jaaskelainen at tut.fi>> wrote: Well, To be honest I'm not very comfortable with the whole constant G...

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

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

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 irrelevant for corner conditions) to get valid SPIR that it is *very* difficult to get into a shape that you can code generate for CPUs. E...

...;) 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 parallel implementations). 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. On 09/24/2012 05:00 PM, James Molloy wrote: > 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&quo...

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 24 September 2012 15:08, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi>wrote: > >> Well, >> >> To be honest I'm not very comfortab...

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

Indeed; I agree it is not an implementation detail as potentially valid SPIR could be almost untranslatable to valid code running on a target without dedicated workgroup-local memory. Micah: the problem can be distilled down to: __local variables in SPIR are represented as Constants (GlobalVariable : public Constant), but they are not in fact constant, for a device with no workgroup-local memory.

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