[PATCH] Always emit function declaration when generating profile instrumentation

[Reid Kleckner]

On Wed, May 28, 2014 at 3:21 PM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

> I agree that this isn't useful for PGO, but the profile data is also useful
> for code coverage.
>
> Given profile data, consider answering the questions:  "What functions were
> instrumented?  Which of these had no coverage?"  I'm not sure how to answer
> those questions accurately without these counters.
>
> This still leaves coverage gaps in never-used templated code, but that's a
> different can of worms.


Emitting all inline functions seems like it will require semantic changes
and it's overkill.  The specific case I'm thinking of is:
#include <memory>
struct Bar;
struct Foo {
  Foo(Bar *b) : p(b) {}
  std::unique_ptr<Bar> p;
};

We need to require a complete type for Bar if we want to emit ~Foo, because
~unique_ptr<Bar> deletes Bar, but we don't require that currently.

I don't know the details of coverage, but is there another way to represent
"I saw this inline function, but nobody called it"?  My straw man
suggestion is to emit a single counter for the entry block that will either
always be zero or be comdat merged with another TU that uses the inline
function.


> > Also, CodeGenerator::HandleInlineMethodDefinition() would be a better
> place for this code.  We recently added it for dllexport, which has
> basically the semantics you want.  If this ends up being the direction we
> want, we probably want to merge support for -femit-all-decls, pgo, and
> dllexport in the same place to control the linkage and MustBeEmitted-ness
> of inline functions.
>
> That sounds like a better design (assuming you agree on the direction).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140528/50df2a70/attachment.html>