<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 7:08 PM Kyungwoo Lee via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</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">kyulee added a comment.<br>
<br>
In D104060#2823466 <<a href="https://reviews.llvm.org/D104060#2823466" rel="noreferrer" 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.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">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.</div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">Edge profiling helps size optimization as well -- we recently added OptimizeForSize support at BB level so that cold blocks can be better size optimized. </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)">Another plug -- if you are interested in size optimization, the ML based size optimization is also available in LLVM -- it beats -Oz.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">-fcs-profile-generate is very late in the IR pipeline after inlining transformations, so there is very little information loss when passing to MIR.</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">
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.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">Do you mean 'converting MIP' for IR passes?</div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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.<br>
</blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">yes.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
</blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">It is fine to do this under an option and produce profile data with different magic number or flavor bit -- this is well supported.</div><br></div><div><br></div><div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)">David</div><div class="gmail_default" style="font-family:monospace;font-size:small;color:rgb(0,0,0)"></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">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/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D104060/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D104060" rel="noreferrer" target="_blank">https://reviews.llvm.org/D104060</a><br>
<br>
</blockquote></div></div>