llvm dev - Mar 2014 - [LLVMdev] RFC: Binary format for instrumentation based profiling data

On Mar 13, 2014, at 2:14 PM, Diego Novillo <dnovillo at google.com> wrote:
> On Thu, Mar 13, 2014 at 11:51 AM, Bob Wilson <bob.wilson at
apple.com> wrote:
>> 
>> On Mar 13, 2014, at 5:48 AM, Diego Novillo <dnovillo at
google.com> wrote:
>>> 
>>> 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).
> 
> Sorry, you lost me.  How exactly does the FE map them to the code? In
> the sample profiler, each instrumented line consists of a line offset,
> a discriminator (to distinguish distinct control flow paths on the
> same line) and the counter. We match them by computing the absolute
> line number from the offset and assign the counter to the
> corresponding basic block.
This is a proposal for the instrumentation-based approach that I talked about at
the dev meeting. I don’t see how it can share the a file format with the sample
profiler, since the content is fundamentally different.
> 
> I think we should be able to use the same pass in
> lib/Transforms/Scalar/SampleProfile.cpp to read profiles generated
> from instrumentation. The information is basically the same, so a bit
> of generalization of that code should be all we need to pass those
> counters down into the analysis module.
?? The information is completely different.

On Mar 13, 2014 6:57 PM, "Bob Wilson" <bob.wilson at apple.com>
wrote:
>
> This is a proposal for the instrumentation-based approach that I talked
about at the dev meeting. I don't see how it can share the a file format
with the sample profiler, since the content is fundamentally different.

It is?  But we're fundamentally emitting similar information, right?

Sample counts and instrumentation counts will be different values, sure.
But they convey the same meaning. Higher values mean higher frequency of
execution.

I'm not saying that the file format must be the same. I'm saying that we
should be able to feed block frequency information and branch probability
information in the same way from both instrumentation and sampling data.

So, in the backend pass that reads profile data we should be able to
process both sample data or instrumentation data. The reader layer just
needs to be smart enough to know what it's reading. But it ultimately feeds
the same information in the form of branch weights.

Diego.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140313/a5b2a74c/attachment.html>

On Thursday, March 13, 2014, Diego Novillo <dnovillo at google.com> wrote:
>
> On Mar 13, 2014 6:57 PM, "Bob Wilson" <bob.wilson at
apple.com<javascript:_e(%7B%7D,'cvml','bob.wilson at
apple.com');>>
> wrote:
>
> >
> > This is a proposal for the instrumentation-based approach that I
talked
> about at the dev meeting. I don't see how it can share the a file
format
> with the sample profiler, since the content is fundamentally different.
>
> It is?  But we're fundamentally emitting similar information, right?
>
> Sample counts and instrumentation counts will be different values, sure.
> But they convey the same meaning. Higher values mean higher frequency of
> execution.
>
> I'm not saying that the file format must be the same. I'm saying
that we
> should be able to feed block frequency information and branch probability
> information in the same way from both instrumentation and sampling data.
>
> So, in the backend pass that reads profile data we should be able to
> process both sample data or instrumentation data. The reader layer just
> needs to be smart enough to know what it's reading. But it ultimately
feeds
> the same information in the form of branch weights.
>
The instrumentation based profiling is done in the front end, and the
counters are related to parts do the AST. Their isn't enough information
for a backend pass to map them to *anything*. We feed block frequency and
branch probability through metadata, much like the sampling based approach,
but it happens during irgen in the front end, rather than in a backend pass.

While it might be possible to translate the instrumentation format to the
profile format, it wouldn't be possible to go the other way, and the
translation would be imperfect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140313/7330fd9f/attachment.html>