Micah, Boaz,<div><br></div><div>Do you guys have any ideas about how to fix this issue?</div><div><br></div><div><br></div><div>Cheers,</div><div><br></div><div>James<br><br><div class="gmail_quote">On 24 September 2012 16:04, James Molloy <span dir="ltr"><<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">For the record, I just workarounded it in pocl by borrowing the<br>
</span><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">BreakConstantGEPs code from SAFECode. But for SPIR specs, IMHO, this should<br></span><span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif">be reconsidered.</span></blockquote>

<div><font color="#222222" face="arial, sans-serif"><br></font></div></div><div><font color="#222222" face="arial, sans-serif">Yes, I agree.<br></font><div><div class="h5"><br><div class="gmail_quote">On 24 September 2012 15:08, Pekka Jääskeläinen <span dir="ltr"><<a href="mailto:pekka.jaaskelainen@tut.fi" target="_blank">pekka.jaaskelainen@tut.fi</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Well,<br>
<br>
To be honest I'm not very comfortable with the whole constant GEP<br>
idea. It's a new thing to me and I do not fully understand its<br>
point in LLVM IR, so I probably wasn't very clear ;)<br>
<br>
Anyways, me bringing it up was meant as an example of what can happen<br>
if one (mis)uses the C function static variable semantics for something that<br>
really is a thread local variable (in usual thread parallel implementations).<br>
<br>
For the record, I just workarounded it in pocl by borrowing the<br>
BreakConstantGEPs code from SAFECode. But for SPIR specs, IMHO, this should<br>
be reconsidered.<div><br>
<br>
On 09/24/2012 05:00 PM, James Molloy wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Hi,<br>
<br>
Sorry, With a prod from Silviu (cc'd) I now understand - I was interpreting<br>
your use of "constant GEP" as "GEP with constant operand" as opposed to<br>
"ConstantGEP node" which of course can only take a Constant* operand, not a<br>
Value* operand.<br>
<br>
I now fully see the problem and realise that my solution is also prone to<br>
that problem :)<br>
<br>
Cheers,<br>
<br>
James<br>
<br>
On 24 September 2012 14:41, James Molloy <<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a><br></div><div>
<mailto:<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.<u></u>uk</a>>> wrote:<br>
<br>
Hi,<br>
<br>
I don't fully understand your problem description.<br>
<br>
...is caused by LLVM/Clang thinking<br>
<br>
they are buffers with a constant base which they eventually won't be in a<br>
parallel WG implementation. This triggers an issue I'm currently working on<br>
pocl: <a href="https://bugs.launchpad.net/pocl/+bug/1032203" target="_blank">https://bugs.launchpad.net/<u></u>pocl/+bug/1032203</a> because Clang generates<br>
constant GEPs for the local buffer accesses (even though in a parallel<br>
thread-safe implementation the local variables cannot be stored to constant<br>
locations).<br>
<br>
<br>
Surely if you're passing in pointers to the kernel function that differ<br>
depending on workgroup, then a GEP from those pointers of a constant amount<br>
is perfectly safe. Why would a constant GEP from a per-workgroup base be a<br>
problem?<br>
<br>
<br>
I'm sure there's something I've misunderstood about your solution...<br>
<br>
Cheers,<br>
<br>
James<br>
<br>
On 24 September 2012 12:41, Pekka Jääskeläinen <<a href="mailto:pekka.jaaskelainen@tut.fi" target="_blank">pekka.jaaskelainen@tut.fi</a><br></div><div><div>
<mailto:<a href="mailto:pekka.jaaskelainen@tut.fi" target="_blank">pekka.jaaskelainen@<u></u>tut.fi</a>>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi all,<br>
<br>
Another OpenCL C implementation issue I'm currently fighting with<br>
</blockquote>
is how<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
to best implement the automatic __local variables. Seems SPIR<br>
</blockquote>
enforces<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the current Clang implementation of them that converts the automatic<br>
locals to C function static variables (thus, in practice global<br>
</blockquote>
variables).<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Clearly, this is not a thread safe "final implementation", thus<br>
</blockquote>
works as is<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
only when multiple work groups of the same kernel are not executed in<br>
parallel. Therefore, some other compiler pass is assumed to<br>
</blockquote>
convert those<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
function static (module global variables) to some other storage<br>
</blockquote>
where the<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
local buffers are allocated per work group thread.<br>
<br>
The pocl implementation is what was suggested some time ago in<br>
</blockquote>
this list:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the locals are converted to local arguments to the kernel<br>
</blockquote>
function which<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
are then passed per-thread buffers when the work group is<br>
</blockquote>
executed. Thus,<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
pocl needs to convert the references to these dummy globals to local<br>
buffer pointers at the end of the kernel function argument list.<br>
<br>
The problem from the use of the "semantically inadequate" 'function<br>
static' variables for the local buffers is caused by LLVM/Clang<br>
</blockquote>
thinking<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
they are buffers with a constant base which they eventually won't<br>
</blockquote>
be in<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
a parallel WG implementation. This triggers an issue I'm<br>
</blockquote>
currently working<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
on pocl: <a href="https://bugs.launchpad.net/pocl/+bug/1032203" target="_blank">https://bugs.launchpad.net/<u></u>pocl/+bug/1032203</a> because Clang<br>
generates constant GEPs for the local buffer accesses (even though in a<br>
</blockquote>
parallel<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
thread-safe implementation the local variables cannot be stored to<br>
constant locations).<br>
<br>
So, I wonder if this piece of SPIR specs might cause other similar<br>
problems (LLVM optimizing incorrectly due to the slightly wrong<br>
</blockquote>
semantics)<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
in the future and should be improved. The minimal fix would be to add<br>
some kind of attribute to the function static global that<br>
</blockquote>
prevents<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Clang/LLVM thinking the address is constant and apply<br>
</blockquote>
optimizations that<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
rely on that. Semantically the local buffer is actually a thread-local<br>
</blockquote>
variable.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are thread locals somehow supported in LLVM IR?<br>
<br>
<br>
On 09/13/2012 12:19 PM, Pekka Jääskeläinen wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For what it's worth, this issue manifests itself in an unsolved pocl<br>
bug: <a href="https://bugs.launchpad.net/pocl/+bug/987905" target="_blank">https://bugs.launchpad.net/<u></u>pocl/+bug/987905</a><br>
<br>
It would be simpler to implement a portable implementation for<br>
</blockquote></blockquote>
calling the<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
kernel from the host if we could assume the kernel calling<br>
</blockquote></blockquote>
convention<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
mapped each OpenCL setArg arg to a single kernel function arg (and<br>
</blockquote></blockquote>
preferably all<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
arg data in memory). For the non-kernel functions it should not<br>
</blockquote></blockquote>
matter and<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
could be target-specific.<br>
<br>
</blockquote>
<br>
<br>
-- Pekka<br>
</blockquote>
<br>
<br>
</div></div></blockquote><span><font color="#888888">
<br>
<br>
-- <br>
Pekka<br>
</font></span></blockquote></div><br></div></div></div>
</blockquote></div><br></div>