[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