<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 22, 2014 at 1:18 AM, Justin Bogner <span dir="ltr"><<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> writes:<br>
> I think it would be worthwhile to consider the alternative of having<br>
> the profile library write out data files in a format which is<br>
> essentially "always" transformed by a post-processing tool before<br>
> being used during compilation.<br>
<br>
</div>We seem to have some agreement that two formats for instrumentation<br>
based profiling is worthwhile. These are that emitted by compiler-rt in<br>
the instrumented program at runtime (format 1), and that which is<br>
consumed by clang when compiling the program with PGO (format 2).<br>
<br>
Format 1<br>
--------<br>
<br>
This format should be efficient to write, since the instrumented program<br>
should run with as little overhead as possible. This also doesn't need<br>
to be stable, and we can assume the same version of LLVM that was used<br>
to instrument the program will read the counter data. As such, the file<br>
format is versioned (so we can easily reject versions we don't<br>
understand) and consists basically of a memory dump of the relevant<br>
profiling counters.<br></blockquote><div><br></div><div>This makes perfect sense to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Format 2<br>
--------<br>
<br>
This format should be efficient to read and preferably reasonably<br>
compact. We'll convert from format 1 to format 2 using llvm-profdata,<br>
and clang will use format 2 for PGO.<br>
<br>
Since the only particularly important operation in this use case is fast<br>
lookup, I propose using the on disk hash table that's currently used in<br>
clang for AST serialization/PTH/etc with a small amount of metadata in a<br>
header.<br>
<br>
The hash table implementation currently lives in include/clang/Basic and<br>
consists of a single header. Moving it to llvm and updating the clients<br>
in clang should be easy. I'll send a brief RFC separately to see if<br>
anyone's opposed to moving it.<br></blockquote><div><br></div><div>I can mention this and we can discuss this on the other thread if you would rather, but I'm not a huge fan of this code. My vague memory was that this was a quick hack by Doug that he never really expected to live long-term.</div>
<div><br></div><div>I have a general preference for from-disk lookups to use tries (for strings, prefix tries) or other fast, sorted lookup structures. They have the nice property of being inherently stable and unambiguous, and not baking any hashing algorithm into it.</div>
<div><br></div><div>I've not thought enough about how to make a general purpose one of these to have a stronger opinion though; perhaps I should do so...</div></div></div></div>