<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>The requirement in OpenCL is that all threads (work-items) are required to hit the same barrier.  If one does what you have shown below, it is not legal because some threads may go through the block with S1 and some other threads will go the other way.  On some hardware, such a program will cause a hardware stall. If one is inlining, it is preferable to inline early assuming the rest of the transformations don't mess with the barrier. Eli is correct that you can't duplicate calls to a function containing these kind of barriers for the same reasons.  From the discussions so far, it would be nice if such a concept where you don't want to modify the control flow of a basic block containing such an execution barrier or a function containing such a barrier. This requires that all phases that does such optimizations would have to be made aware of it.  Such a concept may be also useful for other things like inline assembly where one may not want to duplicate a block.</div><div><br></div><div>  -- Mon Ping<br><div><div><div><div><div><div><div><div><div><div><br><div><br></div><div><br><div><div>On Oct 8, 2009, at 11:17 PM, Vinod Grover wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Is inlining (which duplicates code) of functions containing OpenCL style barriers legal?<div>or e.g. </div><div><br></div><div>if you had some changed phase ordering where you had</div><div><br></div><div>if (cond) {</div>
<div>   S1;</div><div>}</div><div>call user_func() // user_func has a barrier buried inside it.</div><div><br></div><div>you do tail splitting</div><div><br></div><div>if (cond) {</div><div>   S1; </div><div>   call user_func()</div>
<div>} else {</div><div>   call user_func();</div><div>}</div><div><br></div><div>now you inline -- oops now you might have a problem</div><div><br></div><div>so do you want IPA to propagate the barrier bit to the call sites?</div>
<div><br></div><div>you could do inlining before tail splitting</div><div><br></div><div>sounds messy...</div><div><br></div><div>Vinod</div><div><br><br><div class="gmail_quote">On Thu, Oct 8, 2009 at 8:38 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com">eli.friedman@gmail.com</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">On Thu, Oct 8, 2009 at 2:11 PM, Reid Kleckner <<a href="mailto:rnk@mit.edu">rnk@mit.edu</a>> wrote:<br>

> IMO Jeff's solution is the cleanest, simplest way to get code that<br>
> works.  Just generate a separate function for every barrier in the<br>
> program, and mark it noinline.  This way the instruction pointers will<br>
> be unique to the barrier.<br>
<br>
</div>No, this gets rather nasty: to support an instruction like this, it<br>
isn't legal to duplicate calls to functions containing a barrier<br>
instruction.<br>
<br>
Another proposal: add an executebarrier function attribute for<br>
functions which directly or indirectly contain an execution barrier,<br>
and adjust all the relevant transformation passes, like jump threading<br>
and loop unswitching, to avoid duplicating calls to such functions.<br>
This puts a slight burden on the frontend to mark functions<br>
appropriately, but I don't see any other solution which doesn't affect<br>
code which doesn't use execute barriers.<br>
<font color="#888888"><br>
-Eli<br>
</font><div><div></div><div class="h5"><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/" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<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></blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div></div></body></html>