llvm dev - Feb 2015 - [LLVMdev] Should we add noduplicate attribute on the function which contains a noduplicate function call?

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

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>

Hello James,

Thanks for your reply.

My apologies that I mark the function 'wait' with noduplicate in the
above
example. In fact I didn't use __attribute__((noduplicate)) with function
'wait' in my implementation so there is no bug in LLVM. I would dig up
the
original discussions between you and Chris Lattner for more context.

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150211/3cec3db1/attachment.html>