On Thursday, March 13, 2014, Diego Novillo <<a href="mailto:dnovillo@google.com">dnovillo@google.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr"><br>
On Mar 13, 2014 6:57 PM, "Bob Wilson" <<a href="javascript:_e(%7B%7D,'cvml','bob.wilson@apple.com');" target="_blank">bob.wilson@apple.com</a>> wrote:</p>
<p dir="ltr">><br>
> 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.</p>


<p dir="ltr">It is?  But we're fundamentally emitting similar information, right?</p>
<p dir="ltr">Sample counts and instrumentation counts will be different values, sure. But they convey the same meaning. Higher values mean higher frequency of execution.</p>
<p dir="ltr">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.</p>


<p dir="ltr">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.<br>

</p></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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. </div>