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

[Bob Wilson]

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.

> 
>> 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.