[PATCH] Always emit function declaration when generating profile instrumentation

[Bob Wilson]

On May 30, 2014, at 1:45 PM, Eric Christopher <echristo at gmail.com> wrote:

> On Fri, May 30, 2014 at 1:43 PM, Bob Wilson <bob.wilson at apple.com> wrote:
>> 
>> On May 30, 2014, at 1:41 PM, Eric Christopher <echristo at gmail.com> wrote:
>> 
>>> On Fri, May 30, 2014 at 1:40 PM, Bob Wilson <bob.wilson at apple.com> wrote:
>>>> 
>>>> On May 28, 2014, at 4:11 PM, Eric Christopher <echristo at gmail.com> wrote:
>>>> 
>>>>> On Wed, May 28, 2014 at 4:08 PM, Duncan P. N. Exon Smith
>>>>> <dexonsmith at apple.com> wrote:
>>>>>> 
>>>>>>> On 2014-May-28, at 15:55, Eric Christopher <echristo at gmail.com> 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.

No, we do not currently have any source location info at all in the PGO data. We have discussed using the debug info to help with that, but it’s not clear what will work best. If the size is reduced significantly by making use of debug info, we will definitely consider using that.