[LLVMdev] Instructions that cannot be duplicated

[Vinod Grover]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091008/a5a3c08a/attachment.html>