search for: constantgep

...the SPIR flaw), the implementers have to work around them with kludges to implement the real automatic local semantics. What's worse, at some point there might be an optimization that is not easily worked around which makes this part of the SPIR specs look bad. Of course it's possible the constantGEP case was the only problem we will ever get from this issue, but I wouldn't rely on it in an IR standard specification if it's possible to avoid it. BR, -- Pekka

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

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 September 2012 14:41, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > I do...

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

...;) 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&qu...

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

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

...ters have to work around them with kludges to implement the real > automatic local semantics. What's worse, at some point there might be > an optimization that is not easily worked around which makes this part of > the > SPIR specs look bad. > > Of course it's possible the constantGEP case was the only problem we will > ever get from this issue, but I wouldn't rely on it in an IR standard > specification if it's possible to avoid it. > > BR, > -- > Pekka > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://list...

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