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

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

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/llvm-dev/attachments/20120924/75036140/attachment.html>

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/llvm-dev/attachments/20120924/35c8ccd4/attachment.html>