<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">I’ve run into the same issue. Some of the optimizations (e.g. jump threading) will duplicate code. Once your barrier function has been inlined it loses the noduplicate
 attribute. Therefore you should not inline your barrier function until the problematic passes run. The noinline attribute on the barrier function can be useful for this. However, you should note that you can’t combine noduplicate and noinline in current Clang.
 One of two gets ignored (I don’t remember which). You have to combine them at the IR level.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">Brandon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
<b>On Behalf Of </b>Lu Mitnick<br>
<b>Sent:</b> Thursday, February 05, 2015 11:37 AM<br>
<b>To:</b> llvmdev@cs.uiuc.edu<br>
<b>Subject:</b> [LLVMdev] Is there any known bug related to NoDuplicate in LLVM/Clang 3.5<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Hello all,<br>
<br>
I am using LLVM/Clang 3.5 to build a C++ extension. Such C++ extension contains a special function named "barrier", which shouldn't be duplicated. So I add __attribute__((noduplicate)) on barrier declaration.<br>
<br>
For some reasons, I also add AlwaysInlineAttr attribute on each function except main function. The generated LLVM IR what I expect is only a main function with many LLVM IRs.<br>
<br>
However when I counts the number of barrier function call of the output LLVM IR, I found the number is more than I used in source code. I am wondering whether there is any known bug related to NoDuplicate in LLVM/Clang 3.5?<br>
<br>
PS. To find out the problematic LLVM pass that may duplicate my barrier function call. I also used -print-after-all to dump the generated LLVM IR of each pass. But the main function is too huge and the called pass is too much therefore it is not feasible to
 debug in this way. Do you have any other debug tips to find out the problematic LLVM pass?<br>
<br>
Any suggestion is welcomed.<br>
<br>
Thanks,<br>
Yi-Hong<o:p></o:p></p>
</div>
</div>

<DIV>
<HR>
</DIV>
<DIV>This email message is for the sole use of the intended recipient(s) and may 
contain confidential information.  Any unauthorized review, use, disclosure 
or distribution is prohibited.  If you are not the intended recipient, 
please contact the sender by reply email and destroy all copies of the original 
message. </DIV>
<DIV>
<HR>
</DIV>
</body>
</html>