[PATCH] Always emit function declaration when generating profile instrumentation

Duncan P. N. Exon Smith dexonsmith at apple.com
Thu May 29 13:33:56 PDT 2014


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

Maybe weak_odr is better than linkonce_odr, but without @llvm.used they'll
be discarded during LTO.

> I don't know enough about what goes into the counters to figure out the odr issue.

Yeah, I'll have to think about this.



More information about the cfe-commits mailing list