> On 2014-May-28, at 17:58, Reid Kleckner <[email protected]> wrote:
> 
> On Wed, May 28, 2014 at 4:00 PM, Duncan P. N. Exon Smith 
> <[email protected]> wrote:
> 
> > On 2014-May-28, at 15:48, Reid Kleckner <[email protected]> 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.
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to