[LLVMdev] RFC: Binary format for instrumentation based profiling data

[Justin Bogner]

Bob Wilson <bob.wilson at apple.com> writes:
> On Mar 13, 2014, at 5:48 AM, Diego Novillo <dnovillo at google.com> wrote:
>
>> On Wed, Mar 12, 2014 at 9:09 PM, Justin Bogner <mail at justinbogner.com> wrote:
>> 
>>> Functions are represented by strings, determined by the part of the
>>> frontend that both generates and uses this data.  In our case, these are
>>> generally whatever clang thinks of as the function's name, with minor
>>> details added to disambiguate names that aren't necessarily unique.
>> 
>> Why not just use mangled names here? No need to add minor details, nor
>> ad-hoc disambiguation. If you're already using mangled names, then I'm
>> not sure why we need disambiguating details.
>
> We need to prepend the file name to distinguish functions with local
> linkage. Also, Objective-C methods do not get mangled, so we don’t
> want to say that we just use the mangled names.

Notably, we do use mangled names where we can, and we only add anything
in cases where it isn't enough.

>>> The counter data is simply an array of unsigned 64 bit values.  Given an
>>> offset found in the index, a sequence follows:
>>> 
>>>   <function hash> <number of counters> <counters...>
>>> 
>>> This is all of the data needed for a given function.
>> 
>> How are counters represented? Are these line numbers together with the
>> counter? Basic blocks? Edges?
>
> There are no line numbers, basic blocks, or edges. It is just a
> sequence of counters that the front-end knows how to map to the code
> (the same as with our current textual file format).
>
>> 
>> I wonder if it would make sense to use the existing gcov format for
>> this. OTOH, we could provide a converter in the Profile library.
>
> This is pretty clearly a different format from gcov, and I don’t see
> how we could convert between them. But, I agree that it would be nice
> to collect the code for handling different kinds of profile formats in
> one library, even if those file formats are not interchangeable.