<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 06/26/2014 09:43 AM, Alex L wrote:<br>
</div>
<blockquote
cite="mid:CAKS3GBtPWPOTRo8wfj=3WNrdeRAGp3Jh8KoAEYumjYez13EiMw@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">2014-06-25 17:57 GMT-07:00 Eric
Christopher <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">So, any
reason why we want the new coverage system? You didn't
seem to<br>
highlight what you saw wrong with gcov or the way it
works.<br>
<br>
I saw your original mail and it didn't have a lot of
motivation here.<br>
<br>
Thanks.<br>
<br>
-eric<br>
</blockquote>
<div><br>
</div>
<div>I am not very familiar with GCOV, but the primary
motivation for the new coverage system is to provide very
accurate execution counts for a program. This would enable
us to provide modern, high quality tools for code coverage
analysis. <br>
<br>
By very accurate I mean that instead of reasoning about
code coverage for basic blocks, branches and even lines,
we would be able to reason about code coverage for the
regions of source code that resemble the corresponding
AST. This would enable the coverage tool to locate and
mark the exact regions of code that weren't executed, even
if the IR for those regions was transformed by the
optimizer. I think that GCOV fails to provide coverage for
certain constructs when optimizations are enabled. Also, I
think that GCOV doesn't really show good coverage for the
lines that have multiple regions with different execution
counts, and the new system will enable us to create a tool
which will have a better way to deal with this particular
situation.<br>
<br>
</div>
<div>Also, the GCOV way produces separate mapping files and
counter files for each source file/object file, which can
be somewhat inconvenient. In the new system we pack the
mapping data into the generated IR and allow it to be
merged by the linker, and as a result of that all our
mapping information is embedded inside the program's
executable.<br>
</div>
<div> <br>
</div>
<div>The new coverage tool will be able to provide a more
interactive experience as well, by showing reports or code
coverage only for selected items like certain functions,
classes, etc.<br>
</div>
<div>
<br>
</div>
<div>Also, this new coverage system will provide a library
which various code coverage tools can use to make coverage
reports without the need to parse the output of GCOV.<br>
</div>
</div>
</div>
</div>
</blockquote>
I find nothing in the above explanation to justify including this
code *in LLVM*. Such a tool may be useful, but this really sounds
like an independent project (i.e. "replace gcov"). <br>
<br>
Glancing through the code, I also see no real interaction with
LLVM. This really seems like an independent profiling library which
could be used to provide profiling data to LLVM, but is otherwise
unrelated. Correct me if I'm wrong here - I did a *very* quick
scan.<br>
<br>
Your post about this topic on llvm-dev has not generated any
consensus. If anything, there seems to be an active disinterest in
your proposal. <br>
<br>
Given the above, I would oppose the inclusion of this change set. <br>
<br>
<br>
<blockquote
cite="mid:CAKS3GBtPWPOTRo8wfj=3WNrdeRAGp3Jh8KoAEYumjYez13EiMw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5">
On Wed, Jun 25, 2014 at 4:32 PM, Alex L <<a
moz-do-not-send="true"
href="mailto:arphaman@gmail.com">arphaman@gmail.com</a>>
wrote:<br>
> Hi everyone,<br>
> This is a first patch that implements the data
structures, readers and<br>
> writers used by the new code coverage system. I
added the new code to the<br>
> ProfileData library. I also added a very minimal
C api for the ProfileData<br>
> library.<br>
><br>
> <a moz-do-not-send="true"
href="http://reviews.llvm.org/D4301" target="_blank">http://reviews.llvm.org/D4301</a><br>
><br>
><br>
><br>
</div>
</div>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a moz-do-not-send="true"
href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a moz-do-not-send="true"
href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits"
target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
><br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
llvm-commits mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a>
</pre>
</blockquote>
<br>
</body>
</html>