<div dir="ltr"><div class="gmail_default" style="font-family:monospace;font-size:small;color:#000000">Do you have runtime number with -fcs-profile-generate -mllvm -disable-vp=true</div><div class="gmail_default" style="font-family:monospace;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:monospace;font-size:small;color:#000000">This will provide more data (BB count) than what MIP can do.</div><div class="gmail_default" style="font-family:monospace;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:monospace;font-size:small;color:#000000">Besides, more options can be added to control the type of profile data collected in IRPGO to further reduce overhead.</div><div class="gmail_default" style="font-family:monospace;font-size:small;color:#000000"><br></div><div class="gmail_default" style="font-family:monospace;font-size:small;color:#000000">David</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 11, 2021 at 3:46 PM Ellis Hoag 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">ellis added a comment.<br>
<br>
I've collected some size and runtime metrics from `llvm-test-suite`. The steps and results can be found in this gist: <a href="https://gist.github.com/ellishg/92a68cf82bfdeccd10225154425edc69" rel="noreferrer" target="_blank">https://gist.github.com/ellishg/92a68cf82bfdeccd10225154425edc69</a><br>
<br>
Keep in mind that a major goal is that MIP instrumented binaries should be as small as possible without sacrificing usability or functionality. The metrics that I measured in the gist are the binary size and the execution time of instrumented binaries. Like I said in the description, MIP instrumented binaries are usually 2-5% larger than non-instrumented binaries. We can compare this to the `-fsanitize-coverage=func,inline-bool-flag,pc-table` flag which seems to produce instrumented binaries that can be 100x larger. The extra size likely comes from the function metadata that is left in the binary, whereas MIP extracts all excess metadata out of the binary.<br>
<br>
I also looked into comparing against `-finstrument-function-entry-bare` and `-finstrument-functions`. It seems that they inject calls to `void __cyg_profile_func_enter_bare();` or `void __cyg_profile_func_enter (void *this_fn, void *call_site);` at the start of each function. The first flag doesn't really provide enough context know the caller and mark it as covered. The second does provide this information, but it still would require some work to collect profile data in a consumable way as MIP does. That being said, these flags seem provide similar size and runtime overhead as MIP, albeit with much less functionality.<br>
<br>
It should also be noted that all this is only considering MIP function coverage. MIP can profile much more data including call counts and the dynamic call graph, likely with very similar performance metrics.<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>