<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">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 class=""><br>
On Feb 17, 2014, at 5:13 AM, Kostya Serebryany <<a href="mailto:kcc@google.com">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>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>