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

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>

On Thu, Mar 13, 2014 at 9:19 PM, Justin Bogner <mail at
justinbogner.com>wrote:
>
> 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.
>
Ah, OK. At least we get the annotations through to the backend. So,
instrumentation gathers both block and edge weights? Or do you derive edge
weights from blocks?

>
> 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.
>
I'm only interested in passing the instrumentation down to the back end.
Are you folks thinking of doing other kinds of instrumentation? (value
profiling, for example).


Thanks. Diego.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140314/0ff6a155/attachment.html>

On Mar 14, 2014, at 5:40 AM, Diego Novillo <dnovillo at google.com> wrote:
> 
> 
> 
> On Thu, Mar 13, 2014 at 9:19 PM, Justin Bogner <mail at
justinbogner.com> wrote:
> 
> 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.
> 
> Ah, OK. At least we get the annotations through to the backend. So,
instrumentation gathers both block and edge weights? Or do you derive edge
weights from blocks?
The IR only has branch weight metadata, and we add that directly to the branch
instructions. In most cases, we can just use the block counts to calculate the
branch weights, but in a few cases, we insert counters on the edges when that is
necessary to get the correct weights.
>  
> 
> 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.
> 
> I'm only interested in passing the instrumentation down to the back
end. Are you folks thinking of doing other kinds of instrumentation? (value
profiling, for example).
We’ve discussed that possibility but not in any detail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140314/19fe9562/attachment.html>