[PATCH] Always emit function declaration when generating profile instrumentation

[Alex L]

2014-05-28 17:58 GMT-07:00 Reid Kleckner <rnk at google.com>:

> 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;
> }
>

This compiles without problems with my patch - the constructor and
destructor of my_unique_ptr are never instrumented.


> 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/20140529/70848632/attachment.html>