[LLVMdev] Instructions that cannot be duplicated

[Mon Ping Wang]

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.

   -- Mon Ping



On Oct 8, 2009, at 11:17 PM, Vinod Grover wrote:

> Is inlining (which duplicates code) of functions containing OpenCL  
> style barriers legal?
> or e.g.
>
> if you had some changed phase ordering where you had
>
> if (cond) {
>    S1;
> }
> call user_func() // user_func has a barrier buried inside it.
>
> you do tail splitting
>
> if (cond) {
>    S1;
>    call user_func()
> } else {
>    call user_func();
> }
>
> now you inline -- oops now you might have a problem
>
> so do you want IPA to propagate the barrier bit to the call sites?
>
> you could do inlining before tail splitting
>
> sounds messy...
>
> Vinod
>
>
> On Thu, Oct 8, 2009 at 8:38 PM, Eli Friedman  
> <eli.friedman at gmail.com> wrote:
> On Thu, Oct 8, 2009 at 2:11 PM, Reid Kleckner <rnk at mit.edu> wrote:
> > IMO Jeff's solution is the cleanest, simplest way to get code that
> > works.  Just generate a separate function for every barrier in the
> > program, and mark it noinline.  This way the instruction pointers  
> will
> > be unique to the barrier.
>
> No, this gets rather nasty: to support an instruction like this, it
> isn't legal to duplicate calls to functions containing a barrier
> instruction.
>
> Another proposal: add an executebarrier function attribute for
> functions which directly or indirectly contain an execution barrier,
> and adjust all the relevant transformation passes, like jump threading
> and loop unswitching, to avoid duplicating calls to such functions.
> This puts a slight burden on the frontend to mark functions
> appropriately, but I don't see any other solution which doesn't affect
> code which doesn't use execute barriers.
>
> -Eli
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091009/041cdd88/attachment.html>