[PATCH] Always emit function declaration when generating profile instrumentation

[Duncan P. N. Exon Smith]

> On 2014-May-28, at 15:48, Reid Kleckner <rnk at google.com> wrote:
> 
> 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.

Hmm... nice catch.  This would not be a good thing.

> 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.

That's an interesting idea, but when inline functions are used, the counters
are declared `linkonce_odr` so that they'll coallesce between TUs.  This
sounds like it would violate the ODR.  Something similar might work though.
Hmm.