[LLVMdev] Should we add noduplicate attribute on the function which contains a noduplicate function call?

[James Molloy]

Hi Yi-Hong,
It looks like you're asking two questions here. First, your stated
question.

The short answer is that LLVM's noduplicate attribute is not semantically
equivalent to OpenCL barriers. It was implemented to help support barriers,
but it has LLVM defined semantics. Specifically, it is explicitly not
transitive. The transitivity property was debated when I added the
attribute, and due to its viral nature was rejected.

The recommended approach to building an OpenCL like compiler was to create
a pass yourself that marked the transitive closure of callers of a
noduplicate function as noduplicate. I believe this is still the advice. I
recommend you dig up the original discussions between me and Chris Lattner
about this for more context, if you need it.

Second, your example. In your example you have marked the function 'wait'
with noduplicate, and simplifycfg is apparently duplicating it. This would
be a bug in LLVM.

Cheers,

James
On Tue, 10 Feb 2015 at 22:17, Yi-Hong Lyu <b95705030 at ntu.edu.tw> wrote:

> Hello all,
>
> I have a question related to noduplicate attribute.
>
> For example, if I have the following source code:
>
> __attribute__((noduplicate)) __attribute__((always_inline)) void wait () {
>     // some code
>     barrier();
>     // some code
> }
>
> __attribute__((noduplicate)) void barrier ();
>
> void f () {
>     // some code
>     wait();
>     // some code
> }
>
> Sometimes I observed a phenomenon that SimplifyCFGPass would transform
> function f to:
>
> void f () {
>     // some code
>     wait();
>     // some code
> critedge:
>     // some code
>     wait();
>     // some code
> }
>
> After the execution of AlwaysInliner, the function f would be:
>
> void f () {
>     // some code
>     barrier();
>     // some code
> critedge:
>     // some code
>     barrier();
>     // some code
> }
>
> It seems that barrier call is duplicated in function f. I am wondering
> whether it is a bug of LLVM. Should we add noduplicate attribute on the
> function which contains a noduplicate function call?
>
> Thanks.
> _______________________________________________
> 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/20150210/c8553cee/attachment.html>