llvm dev - Apr 2011 - [LLVMdev] How to prevent duplication of function calls?

Hello,

Is it possible to prevent duplication of call sites for specific functions
(while still maintaining -O3 optimization level)? For example, the following C
code:

------------------
if (cond1) a=2;
llvm.memory.barrier(...);
------------------

is turned by clang with -O2 into something like this:

------------------
if (cond1)
          a=2;
          llvm.memory.barrier(...);
else
          llvm.memory.barrier(...);
------------------

We're doing C to HDL compilation with LLVM. Having multiple locations that
call llvm.memory.barrier(...) would cause complications to generated hardware.

So far, I can think of only two solutions. One is to add support for something
like "noclone" attribute and update all optimizations to obey it. The
other is to re-merge the calls as a final pass. Any better ideas?

Thank you,
Dmitry


________________________________
Confidentiality Notice.
This message may contain information that is confidential or otherwise protected
from disclosure. If you are not the intended recipient, you are hereby notified
that any use, disclosure, dissemination, distribution, or copying of this
message, or any attachments, is strictly prohibited. If you have received this
message in error, please advise the sender by reply e-mail, and delete the
message and any attachments. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110414/6837da38/attachment.html>

This came up a long time ago, but I'm not sure what the resolution was:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-October/026312.html

There's also TID::isNotDuplicable:
http://llvm.org/docs/doxygen/html/classllvm_1_1TargetInstrDesc.html#ab05b074805f22503828b5b625d437f3a

I don't know enough about LLVM's backend to say if you can get that on
an intrinsic.

Reid

On Thu, Apr 14, 2011 at 5:24 PM, Dmitry Denisenko <DDENISEN at altera.com>
wrote:
> Hello,
>
>
>
> Is it possible to prevent duplication of call sites for specific functions
> (while still maintaining –O3 optimization level)? For example, the
following
> C code:
>
>
>
> ------------------
>
> if (cond1) a=2;
>
> llvm.memory.barrier(...);
>
> ------------------
>
>
>
> is turned by clang with -O2 into something like this:
>
>
>
> ------------------
>
> if (cond1)
>
>           a=2;
>
>           llvm.memory.barrier(...);
>
> else
>
>           llvm.memory.barrier(...);
>
> ------------------
>
>
>
> We’re doing C to HDL compilation with LLVM. Having multiple locations that
> call llvm.memory.barrier(...) would cause complications to generated
> hardware.
>
>
>
> So far, I can think of only two solutions. One is to add support for
> something like “noclone” attribute and update all optimizations to obey it.
> The other is to re-merge the calls as a final pass. Any better ideas?
>
>
>
> Thank you,
>
> Dmitry
>
>
>
> ________________________________
> Confidentiality Notice.
> This message may contain information that is confidential or otherwise
> protected from disclosure. If you are not the intended recipient, you are
> hereby notified that any use, disclosure, dissemination, distribution, or
> copying of this message, or any attachments, is strictly prohibited. If you
> have received this message in error, please advise the sender by reply
> e-mail, and delete the message and any attachments. Thank you.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

Thanks Reid. It looks like the first thread didn't really get anywhere. The
author most likely just modified the offending passes to respect the barriers
(this is my guess based on what I read in that thread).

By the time back-end starts, it's too late, since the front end does some of
the duplications.

For the record, I probably will end up doing the following:
- Modifying passes that duplicate the calls not to do so.
- Marking all barrier calls with a new global variable.
- Assert that no duplication happened (i.e. there are no two barriers that
access the same global marker). If that happens, tell the user to turn down
optimizations until the assert failure goes away :(.

This is a maintenance problem but probably still easier than writing generic
re-merging pass.


Dmitry


-----Original Message-----
From: Reid Kleckner [mailto:reid.kleckner at gmail.com]
Sent: Saturday, April 16, 2011 2:33 PM
To: Dmitry Denisenko
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] How to prevent duplication of function calls?

This came up a long time ago, but I'm not sure what the resolution was:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-October/026312.html

There's also TID::isNotDuplicable:
http://llvm.org/docs/doxygen/html/classllvm_1_1TargetInstrDesc.html#ab05b074805f22503828b5b625d437f3a

I don't know enough about LLVM's backend to say if you can get that on
an intrinsic.

Reid

On Thu, Apr 14, 2011 at 5:24 PM, Dmitry Denisenko <DDENISEN at altera.com>
wrote:
> Hello,
>
>
>
> Is it possible to prevent duplication of call sites for specific functions
> (while still maintaining –O3 optimization level)? For example, the
following
> C code:
>
>
>
> ------------------
>
> if (cond1) a=2;
>
> llvm.memory.barrier(...);
>
> ------------------
>
>
>
> is turned by clang with -O2 into something like this:
>
>
>
> ------------------
>
> if (cond1)
>
>           a=2;
>
>           llvm.memory.barrier(...);
>
> else
>
>           llvm.memory.barrier(...);
>
> ------------------
>
>
>
> We’re doing C to HDL compilation with LLVM. Having multiple locations that
> call llvm.memory.barrier(...) would cause complications to generated
> hardware.
>
>
>
> So far, I can think of only two solutions. One is to add support for
> something like “noclone” attribute and update all optimizations to obey it.
> The other is to re-merge the calls as a final pass. Any better ideas?
>
>
>
> Thank you,
>
> Dmitry
>
>
>
> ________________________________
> Confidentiality Notice.
> This message may contain information that is confidential or otherwise
> protected from disclosure. If you are not the intended recipient, you are
> hereby notified that any use, disclosure, dissemination, distribution, or
> copying of this message, or any attachments, is strictly prohibited. If you
> have received this message in error, please advise the sender by reply
> e-mail, and delete the message and any attachments. Thank you.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

Confidentiality Notice.
This message may contain information that is confidential or otherwise protected
from disclosure. If you are not the intended recipient, you are hereby notified
that any use, disclosure, dissemination, distribution,  or copying  of this
message, or any attachments, is strictly prohibited.  If you have received this
message in error, please advise the sender by reply e-mail, and delete the
message and any attachments.  Thank you.