<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:monospace;font-size:small;color:#000000"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 16, 2021 at 8:46 PM Kyungwoo Lee <<a href="mailto:kyulee@fb.com">kyulee@fb.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-3830263480215246297WordSection1">
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Wed, Jun 16, 2021 at 7:08 PM Kyungwoo Lee via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">kyulee added a comment.<br>
<br>
In D104060#2823466 <<a href="https://reviews.llvm.org/D104060#2823466" target="_blank">https://reviews.llvm.org/D104060#2823466</a>>, @MaskRay wrote:<br>
<br>
> I think people's main question is what distinguishing features make MachineFunction instrumentation appealing.<br>
><br>
>> MIP Edge Profile, Optimization<br>
><br>
> The two are very inconvenient at the MachineFunction/MachineBasicBlock level...<br>
> I don't know how you can make edge profiling work for BB transitions...<br>
<br>
MIP does not (cannot) collect BB edge data but MachineBlock coverage as needed (optional).<br>
But, MIP can collect call-edge data for all call-sites including dynamic dispatch calls that are not covered by LLVM IR instrumentation.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_-3830263480215246297MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:12pt;font-family:"Courier New"">IR instrumentation supports indirect call target profiling. I suppose MIP has a lightweight mechanism at the cost of tracking precision? Anyway, I don't think this is not something IR instrumentation
 can not have.<u></u><u></u></span></li></ul>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;font-family:"Courier New""><u></u> <u></u></span></p>
<p class="MsoNormal">I understand IR instrumentation has value-profile for indirect call targets at call-site. I don’t think IR instrumentation covers dynamic dispatch call-site like msgSend whose target resolution happens at runtime. Instead of instrumenting
 each call-site, MIP tracks return address values at the function entry via a sort of back-tracking to reconstruct call-edges regardless of all type of calls – direct, indirect, or dynamic.<br>
MIP does this instrumentation at post-RA where assembly level coding is relatively straightforward. I think doing this at IR before frame-lowering will need extra overhead/mechanic to ensure this instrumentation happens in the very beginning of function.<u></u><u></u></p>
<p class="MsoNormal"><u></u> </p></div></div></div></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">Basically the callsite context (counter) is passed to the caller so it can do the profiling. GCC does that too.</div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">For IRPGO, we plan to add dynamic type profiling at some point. Once that is ready, the problem of message passing style call profiling will be handled.</div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">Also if edge profiling is available, profiling direct calls will be a waste as the information can be deduced.</div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)"><br></div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">David</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-3830263480215246297WordSection1"><div><div><div><p class="MsoNormal"><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">As commented earlier, MIP is initially designed for mobile applications where majority calls are dynamic. In this world, size or minimum size optimizations are typically enabled.<br>
So, traditional speed optimizations like inlining or vectorization from BB edge profiles were not a great concern.<br>
Instead, the MIP data were mainly used for ordering, separation, or outlining to minimize CPU penalties while saving as much size as possible.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_-3830263480215246297MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:12pt;font-family:"Courier New"">Edge profiling helps size optimization as well -- we recently added OptimizeForSize support at BB level so that cold blocks can be better size optimized. <u></u><u></u></span></li></ul>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;font-family:"Courier New";color:black"><u></u> <u></u></span></p>
</div>
<div>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_-3830263480215246297MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:12pt;font-family:"Courier New"">Another plug -- if you are interested in size optimization, the ML based size optimization is also available in LLVM -- it beats -Oz.<u></u><u></u></span></li></ul>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
We understand if we want an IR level profile (e.g. BB edge profiles) for IR level optimizations, it would be tricky because MIP instrument Machine IRs.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_-3830263480215246297MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:12pt;font-family:"Courier New"">-fcs-profile-generate is very late in the IR pipeline after inlining transformations, so there is very little information loss when passing to MIR.<u></u><u></u></span></li></ul>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">However, internally we've already experimented a SamplePGO like conversion to generate LLVM IR profile converted from MIP using symbolication.<br>
Certainly this will lose precision, but it's generally good enough in this domain because the majority of speed optimizations will be blocked anyhow under minimum size-opt.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_-3830263480215246297MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:12pt;font-family:"Courier New"">Do you mean 'converting MIP' for IR passes?<u></u><u></u></span></li></ul>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Yes. MIP is not IR-attached, but rather tagged on machine address with which we can easily correlate debug data.
<br>
So, it’s possible to construct a SamplePGO profile that is consumable for IR passes.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
Nonetheless, I think it's also worth revisiting MIP-like implementation at IR level to support full IR profiles including BB edge profile by reusing as much LLVM IR instrumentation code as possible.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_-3830263480215246297MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:12pt;font-family:"Courier New"">yes.<u></u><u></u></span></li></ul>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">I do still think refactoring the profile format of the existing LLVM IR instrumentation for the integration of MIP seems too disruptive while breaking the existing infra or usage.<u></u><u></u></p>
</blockquote>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_-3830263480215246297MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:12pt;font-family:"Courier New"">It is fine to do this under an option and produce profile data with different magic number or flavor bit -- this is well supported.<u></u><u></u></span></li></ul>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<ul style="margin-top:0in" type="disc">
<li class="gmail-m_-3830263480215246297MsoListParagraph" style="color:black;margin-left:0in">
<span style="font-size:12pt;font-family:"Courier New"">David<u></u><u></u></span></li></ul>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12pt">Instead, I'd like to keep the mipmap (metadata) layout in MC to make them extractable, and this means we may retain pseudo ops all the way down to MC from IR.<br>
<br>
<br>
Repository:<br>
  rG LLVM Github Monorepo<br>
<br>
CHANGES SINCE LAST ACTION<br>
  <a href="https://reviews.llvm.org/D104060/new/" target="_blank">https://reviews.llvm.org/D104060/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D104060" target="_blank">https://reviews.llvm.org/D104060</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>

</blockquote></div></div>