[LLVMdev] RFC: Binary format for instrumentation based profiling data
Justin Bogner
mail at justinbogner.com
Thu Mar 13 18:19:43 PDT 2014
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>
More information about the llvm-dev
mailing list