<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=us-ascii">
<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;}
@font-face
        {font-family:Menlo;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
p.gmail-m-5121979616895690931msolistparagraph, li.gmail-m-5121979616895690931msolistparagraph, div.gmail-m-5121979616895690931msolistparagraph
        {mso-style-name:gmail-m_-5121979616895690931msolistparagraph;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle19
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1608191684;
        mso-list-template-ids:823549576;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">I agree with your sentiment that the ProfileData library deals mostly with a profile and not a binary.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">On my end, my team can investigate what we can do to avoid the dependency on Object from ProfileData.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Upstream, the incoming data to the reader is just a buffer of bytes. It was our downstream development that added constructs that dealt with ObjectFiles. If clients of InstrProfReader could perform the section extraction themselves and
 then send the profile name and data in as either StringRefs (SectionRef::getContents) or as a MemoryBuffer (getMemBuffer), we can maintain the independence of ProfData from Object. This would, however, introduce a dependence on Object for clients. Currently
 it looks like the only clients our development cares about is llvm-profdata, which already depends on Object, so nothing would change.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In any case, I’d appreciate being kept in the loop development regarding the removal of the call to getCanonicalFnName, in case that gains traction.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for the insightful discussion,<o:p></o:p></p>
<p class="MsoNormal">JB<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Hongtao Yu <hoy@fb.com> <br>
<b>Sent:</b> Monday, August 9, 2021 3:55 PM<br>
<b>To:</b> Eric Christopher <echristo@gmail.com>; Nagurne, James <j-nagurne@ti.com>; Wenlei He <wenlei@fb.com>; Lei Wang <wlei@fb.com><br>
<b>Cc:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> [EXTERNAL] Re: [llvm-dev] Resolving a dependency circuit in cmake<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="line-height:13.5pt;background:white"><span style="color:black">Thanks for the heads-up. The MC work in discussion here deals with metadata on the binary, while ProfileData mainly deals with a profile without seeing a binary. Thus
 I think it would be more appropriate for the MC work to remain in MC or a third library. The name processing, i.e, calling `</span><span style="font-size:9.0pt;font-family:Menlo;color:#3465A4">FunctionSamples</span><span style="font-size:9.0pt;font-family:Menlo;color:#222222">::getCanonicalFnName</span><span style="color:black">`
 can be  moved into downstream consumer as a post processing. On the other hand, I’m giving a thought of completely removing the use of that function, which, if possible, should be the simplest solution.</span><o:p></o:p></p>
<p class="MsoNormal" style="line-height:13.5pt;background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="line-height:13.5pt;background:white"><span style="color:black">+<a id="OWAAM92283F6C434C484E9A19D27F8B41638F" href="mailto:wenlei@fb.com"><span style="font-family:"Calibri",sans-serif;text-decoration:none">@Wenlei He</span></a>
<a id="OWAAMB6041061E1879146B7492A92FFED734D" href="mailto:wlei@fb.com"><span style="font-family:"Calibri",sans-serif;text-decoration:none">@Lei Wang</span></a></span><o:p></o:p></p>
<p class="MsoNormal" style="line-height:13.5pt;background:white"><o:p> </o:p></p>
<p class="MsoNormal" style="line-height:13.5pt;background:white"><span style="color:black">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal" style="line-height:13.5pt;background:white"><span style="color:black">Hongtao</span><span style="font-size:9.0pt;font-family:Menlo;color:#222222"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>><br>
<b>Date: </b>Monday, August 9, 2021 at 1:05 PM<br>
<b>To: </b>Nagurne, James <<a href="mailto:j-nagurne@ti.com">j-nagurne@ti.com</a>>, Hongtao Yu <<a href="mailto:hoy@fb.com">hoy@fb.com</a>><br>
<b>Cc: </b><a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>><br>
<b>Subject: </b>Re: [llvm-dev] Resolving a dependency circuit in cmake<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><a href="mailto:hoy@fb.com">+hoy@fb.com</a> to bring them into the thread<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">That kind of static function could probably be brought out into a different library, but I think for this some sort of agreement on the dependency chains would be really helpful with what each library is bringing
 to the table here. It might make more sense for the MC work that's been going on here to be happening in ProfileData with that depending on Object and MC to get work done.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Thanks!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">-eric<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Mon, Aug 9, 2021 at 2:42 PM Nagurne, James via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
Hi all,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
 <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
Some background: our team has added Object to the LINK_COMPONENTS of  the ProfileData library as part of work to support code coverage on baremetal emebdded devices.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
Specifically, there is a new type of InstrProfReader that opens an executable and extracts unallocated sections as metadata, rather than relying on a heavyweight runtime call and metadata sections living in restricted target memory.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
 <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
Recently, commit ee7d20e8 (<a href="https://reviews.llvm.org/D106861" target="_blank">https://reviews.llvm.org/D106861</a>) added a dependency on the ProfileData library to the MC library.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
 <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
The combination of these changes causes a dependency circuit that results in link-time failures:<o:p></o:p></p>
<p class="gmail-m-5121979616895690931msolistparagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><![endif]>MC depends on ProfileData<o:p></o:p></p>
<p class="gmail-m-5121979616895690931msolistparagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><![endif]>ProfileData depends on Object<o:p></o:p></p>
<p class="gmail-m-5121979616895690931msolistparagraph" style="margin-left:1.0in;text-indent:-.25in;mso-list:l0 level1 lfo2">
<![if !supportLists]><span style="font-size:10.0pt;font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">        
</span></span></span><![endif]>Object depends on MC<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
 <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
Is there any good way to resolve such dependency circuits in the build system save for an invasive restructuring?<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
 <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
I’ll note that in the review above, MCPseudoProbe only relies upon the static member function FunctionSamples::getCanonicalFnName, which itself relies on a number of static data members of FunctionSamples.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
 <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
Regards,<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
J.B. Nagurne<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
Code Generation<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:.5in">
Texas Instruments<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>