<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Jeff,<div><br></div><div>It’s not really meaningful to talk about threads being created in the context of an OpenCL kernel. The other threads are <i>always</i> present.</div><div><br></div><div>void kernel(int * restrict array, int * restrict array2) {</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>int value = array[0] + get_thread_id() + 1;</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>barrier();</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>array[get_thread_id()] = value;</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>barrier();</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>array2[get_thread_id()] = array[0];</div><div>}</div><div><br></div><div>In this example code, the kernel is well synchronized; there are no data races on any elements of either array. However, the results will differ if we CSE the later read of array[0] with the earlier one. Executed as written, the final value of array2[0] will be array[0]+1. If we perform the CSE, the result will be just array[0].</div><div><br></div><div>—Owen</div><div><br><div><div>On Nov 10, 2013, at 9:16 PM, Jeffrey Yasskin <<a href="mailto:jyasskin@googlers.com">jyasskin@googlers.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Sorry for the delay in getting back to you. I don't know if anything<br>came out of this, since Xiaoyi never wrote back. What does some of the<br>affected code look like? My opinion is still that 'restrict' should<br>mean that no other thread should use a pointer aliasing the restrict<br>pointer, although if many threads are started after the lifetime of<br>the restrict pointer starts, and they depend on the value of the<br>restrict pointer, and they're joined, and then a use of the restrict<br>pointer is moved ahead of the join so that it races with the other<br>threads that depend on the restrict pointer, that's definitely an LLVM<br>bug.<br><br>On Fri, Nov 8, 2013 at 1:50 PM, Owen Anderson <<a href="mailto:resistor@mac.com">resistor@mac.com</a>> wrote:<br><blockquote type="cite">Hi Jeff,<br><br>Do you know if anything came of this? I understand we may need to seek<br>clarification to get a formal answer, particularly with respect to C, but it<br>seems pretty clear to me that this is a significant QoI issue, both for C<br>and CL. LLVM is effectively hoisting a load above a thread-join. This may<br>or may not technically allowed in C, but it seems generally undesirable, and<br>it’s extremely undesirable in CL where these kinds of thread joins are a<br>fundamental of the programming model.<br><br>—Owen<br><br><br>On Aug 6, 2013, at 5:36 PM, Jeffrey Yasskin <<a href="mailto:jyasskin@googlers.com">jyasskin@googlers.com</a>> wrote:<br><br>Chandler pointed out another interpretation of C11/6.7.3.1, in which<br>'restrict' only addresses aliasing within a single thread. If that's<br>the right interpretation, then it's a bug in LLVM that it moves<br>noalias pointers across memory-ordering operations at all, and you<br>still don't need a new fence, just a bug fix.<br><br>6.7.3.1 says "During each execution of B, ...". "During" could either<br>mean just within the same thread or within any segment of a thread<br>that doesn't happen-before or happen-after B.<br><br>It's a defect in C that this is ambiguous. Anyone want to volunteer to<br>send it to the committee? (I'll be happy to proofread, etc., just not<br>be in charge of finding the right email target)<br><br>On Tue, Aug 6, 2013 at 5:01 PM, Jeffrey Yasskin <<a href="mailto:jyasskin@googlers.com">jyasskin@googlers.com</a>><br>wrote:<br><br>This sounds a lot like the question at<br><a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064462.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064462.html</a>. It<br>sounds like you have a pointer marked 'restrict', but it's actually<br>aliased in another thread. That would be undefined behavior even with<br>a stronger fence.<br><br>On Tue, Aug 6, 2013 at 4:56 PM, Guo, Xiaoyi <<a href="mailto:Xiaoyi.Guo@amd.com">Xiaoyi.Guo@amd.com</a>> wrote:<br><br>Hi,<br><br>In OpenCL, the "barrier()" function, as well as various target specific<br>memory fence intrinsics, should prevent loads/stores of the relevant address<br>space from being moved across them.<br>Kernel pointers with "restrict" attributes are implemented by marking the<br>pointer "noalias" in the LLVMIR. However, in LLVM, "noalias" pointers are<br>not affected by llvm memory fence instructions.<br><br>To make sure all loads/stores, including those accessing "restrict" pointers<br>are not moved across the barrier/fence intrinsics, we have considered using<br>customized alias analysis passes. However, we would like to move away from<br>using customized passes and would like to use standard llvm mechanisms as<br>much as possible.<br><br>What do people think about adding an llvm intrinsic, something like<br>llvm.opencl.mem_fence(i32) (or named something that doesn't have opencl in<br>the name, llvm.addrspace_fence?), which acts as a fence for a single given<br>address space (assuming again that there's no problem with implementing<br>these things as a series of different functions to get the full effect), and<br>which prevents even noalias pointers from being moved across it?<br><br>Alternatively (possibly nicer) would be something that looks like the memset<br>intrinsic, which can work for any address space.<br>llvm.addrspace_fence.p1.p2(void)<br>llvm.addrspace_fence.p1(void) ...<br><br>Thanks,<br>Xiaoyi<br><br><br>_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br><br><br>_______________________________________________<br>LLVM Developers mailing list<br>LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu<br>http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev<br><br><br></blockquote></blockquote></div><br></div></body></html>