[PATCH] Always emit function declaration when generating profile instrumentation

[Reid Kleckner]

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

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


A more accurate reduction:

template <typename T>
struct my_unique_ptr {
  my_unique_ptr(T *p) : p(p) {}
  ~my_unique_ptr() { delete p; }
  T *p;
};
struct Bar;
struct Foo {
  Foo();
  my_unique_ptr<Bar> p;
};

My original constructor would have instantiated ~unique_ptr<Bar> from the
inline ctor.


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


They should actually be weak_odr if you don't want them to be discarded.
 IMO this is better than @llvm.used, which has pretty weird semantics.

I don't know enough about what goes into the counters to figure out the odr
issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140528/4d3c786f/attachment.html>