On Fri, May 30, 2014 at 1:43 PM, Bob Wilson <[email protected]> wrote: > > On May 30, 2014, at 1:41 PM, Eric Christopher <[email protected]> wrote: > >> On Fri, May 30, 2014 at 1:40 PM, Bob Wilson <[email protected]> wrote: >>> >>> On May 28, 2014, at 4:11 PM, Eric Christopher <[email protected]> wrote: >>> >>>> On Wed, May 28, 2014 at 4:08 PM, Duncan P. N. Exon Smith >>>> <[email protected]> wrote: >>>>> >>>>>> On 2014-May-28, at 15:55, Eric Christopher <[email protected]> wrote: >>>>>> >>>>>> ... I'll bite. >>>>>> >>>>>> Why do you want to know "this function wasn't instrumented" versus >>>>>> "this had no calls" for coverage? If it's not instrumented it's >>>>>> definitely not called. Otherwise you need to do this for all functions >>>>>> (and who knows what chaos with special member functions that you >>>>>> didn't have to create... :) >>>>> >>>>> I can think of two scenarios: >>>>> >>>>> 1. The error/warning messages should be different: "profile out of date" >>>>> vs. >>>>> "foo() has no coverage". >>>> >>>> This seems ok I guess. Though if you've got a binary you should be >>>> able to say "this code doesn't exist". >>>> >>>>> >>>>> 2. All you have is source and the profile data (i.e., a gcov-like flow, >>>>> without an AST), and you want to output the list of functions with no >>>>> coverage. >>>> >>>> You could just take the ones that you do have coverage info for and >>>> it's the inverse? >>>> >>>> In general I think forcing emission of things that aren't normally >>>> emitted is probably going to be a bit of a problem. >>> >>> I think Eric is right here. >>> >>> Instead of emitting the functions, we should be able to solve this by >>> emitting something to the coverage mapping table (something Alex is >>> starting to work on) to just hardwire the counts for these unused functions >>> to zero. >>> >> >> Sounds about like what Duncan and I were talking about on IRC after >> (apologies for not updating the thread). What do you mean for a >> coverage mapping table? > > We’re still thinking about the details, but we don’t currently have any way > to correlate our “instrumented PGO” data with source locations. We’ll need to > add that for coverage testing.
*nod* I thought you were emitting source locations into the PGO data. If not, then you could map them back via debug information (ala the sample based fdo) by constructing a side table after the fact by parsing debug info. -eric _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
