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

[James Molloy]

>
> 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 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 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" 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
>> <mailto:james at jamesmolloy.co.**uk <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<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
>> <mailto:pekka.jaaskelainen@**tut.fi <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<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<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
>>>
>>
>>
>>
>
> --
> Pekka
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120924/5061d86a/attachment.html>