[LLVMdev] How to prevent duplication of function calls?

[Dmitry Denisenko]

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.