[cfe-dev] [LLVMdev] SPIR provisional specification is now available in the Khronos website

James Molloy james at jamesmolloy.co.uk
Mon Sep 24 07:00:21 PDT 2012


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 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 (even though in a parallel
>> thread-safe implementation the local variables cannot be stored to
>> constant locations).
>>
>
>  Surely if you're passing in pointers to the kernel function that differ
> depending on workgroup, then a GEP from those pointers of a constant amount
> is perfectly safe. Why would a constant GEP from a per-workgroup base be a
> problem?
>
>
> I'm sure there's something I've misunderstood about your solution...
>
> Cheers,
>
> James
>
> On 24 September 2012 12:41, Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi>
> wrote:
> > 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 multiple work groups of the same kernel are not executed in
> > parallel. Therefore, some other compiler pass is assumed to convert those
> > function static (module global variables) to some other storage where the
> > local buffers are allocated per work group thread.
> >
> > The pocl implementation is what was suggested some time ago in this list:
> > the locals are converted to local arguments to the kernel function which
> > are then passed per-thread buffers when the work group is executed. Thus,
> > pocl needs to convert the references to these dummy globals to local
> > buffer pointers at the end of the kernel function argument list.
> >
> > The problem from the use of the "semantically inadequate" 'function
> > static' variables for the local buffers 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 (even though in a parallel
> > thread-safe implementation the local variables cannot be stored to
> > constant locations).
> >
> > So, I wonder if this piece of SPIR specs might cause other similar
> > problems (LLVM optimizing incorrectly due to the slightly wrong
> semantics)
> > in the future and should be improved. The minimal fix would be
> > to add some kind of attribute to the function static global that prevents
> > Clang/LLVM thinking the address is constant and apply optimizations that
> > rely
> > on that. Semantically the local buffer is actually a thread-local
> variable.
> > Are thread locals somehow supported in LLVM IR?
> >
> >
> > On 09/13/2012 12:19 PM, Pekka Jääskeläinen wrote:
> >>
> >> For what it's worth, this issue manifests itself in an unsolved pocl
> >> bug: https://bugs.launchpad.net/pocl/+bug/987905
> >>
> >> It would be simpler to implement a portable implementation for calling
> the
> >> kernel from the host if we could assume the kernel calling convention
> >> mapped
> >> each OpenCL setArg arg to a single kernel function arg (and preferably
> all
> >> arg data in memory). For the non-kernel functions it should not matter
> and
> >> could be target-specific.
> >>
> >
> >
> > --
> > Pekka
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120924/35c8ccd4/attachment.html>


More information about the cfe-dev mailing list