<div dir="ltr">Ah, that's -fprofile-instr-generate</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 19, 2014 at 2:03 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Tue, Feb 18, 2014 at 10:15 PM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Our instrumentation code is basically done now, so you can try it out and compare the performance. Just build with -finstr-profile-generate. </div>
</blockquote><div><br></div></div><div>Is this in trunk?</div><div><div>clang-3.5: error: unknown argument: '-finstr-profile-generate'</div></div><div><br></div><div>--kcc</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word">You may want to hack the compiler-rt code in lib/profile/PGOProfiling.c to disable writing the output, since the current implementation is pretty naive.<div><br></div><div>If it turns out as you suggest, and the different kinds of instrumentation serve different purposes, then I think it would make sense to do both.</div>
<div><div><div><br><div><div>On Feb 18, 2014, at 3:13 AM, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">Regarding performance, I've made a simple coverage with counters and compared it with AsanCoverage.<div>
<br></div><div>AsanCoverage produces code like this:</div><div><div>mov 0xe86cce(%rip),%al</div>
<div>test %al,%al</div><div>je 48b4a0 # to call __sanitizer_cov</div><div>...</div><div>callq 4715b0 <__sanitizer_cov><br></div><div><br></div><div>A simple counter-based thing (which just increments counters and does nothing else useful) produces this: </div>
<div>incq 0xe719c6(%rip)<br></div><div><br></div><div>The performance is more or less the same, although the issue with false sharing still remains</div><div> (<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066116.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-October/066116.html</a>)</div>
<div><br></div><div>Do you have any more details about the planned clang coverage? </div><div><br></div><div>Thanks, </div></div><div><br></div><div>--kcc </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Feb 18, 2014 at 1:00 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Tue, Feb 18, 2014 at 12:20 AM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
On Feb 17, 2014, at 5:13 AM, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:<br>
> Then my question: will there be any objection if I disentangle AsanCoverage from ASan and make it a separate LLVM phase with the proper clang driver support?<br>
> Or it will be an unwelcome competition with the planned clang coverage?<br>
<br>
</div>I don’t view it as a competition, but assuming that we both succeed in our plans, LLVM would then end up with two very similar solutions for code coverage. Does it really make sense to have two?</blockquote><div><br>
</div></div></div><div>It depends. If the two will indeed have the same functionality -- then no.</div><div>My understanding about your plans is that the upcoming coverage will provide "counters" (== how many times a bb/edge was executed).</div>
<div>AsanCoverage produces booleans (== 1, iff a function/bb was executed), which is less information, but faster.</div><div>How much faster -- I can't tell w/o your performance numbers.</div><div>For our early users the performance is critical and booleans are sufficient. </div>
<div><br></div><div>If we end up needing both variants, we may want to keep them similar from user perspective, e.g. have flag combinations like these:</div><div>-coverage=per-edge,counter<br></div><div>-coverage=per-function,counter</div>
<div>-coverage=per-block,counter<br></div><div><div>-coverage=per-function,boolean</div><div>-coverage=per-block,boolean<br></div></div><div><br></div><div> --kcc<br></div></div></div></div>
</blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>