> On 2014-May-28, at 15:48, Reid Kleckner <[email protected]> wrote: > > On Wed, May 28, 2014 at 3:21 PM, Duncan P. N. Exon Smith > <[email protected]> wrote: > I agree that this isn't useful for PGO, but the profile data is also useful > for code coverage. > > Given profile data, consider answering the questions: "What functions were > instrumented? Which of these had no coverage?" I'm not sure how to answer > those questions accurately without these counters. > > This still leaves coverage gaps in never-used templated code, but that's a > different can of worms. > > 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. > 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. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
