[PATCH] Always emit function declaration when generating profile instrumentation

Alex L arphaman at gmail.com
Fri May 30 14:03:19 PDT 2014


2014-05-30 13:40 GMT-07:00 Bob Wilson <bob.wilson at apple.com>:

>
> 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.
>
> Alex, do you think that will work?
>

Yes, that should work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140530/a7334c59/attachment.html>


More information about the cfe-commits mailing list