<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 15, 2016 at 11:41 AM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Tagging profile data with such information is generally useful. My thoughts are<br>
<br>
1) such information is probably not needed to be stored in raw format<br>
profile data -- so no runtime changes are needed -- only llvm-profdata<br>
and indexed format need to be enhanced to support this.<br>
2) A more general way is just add an option:<br>
--embed_label=<customized_label>, where the label is a string can be<br>
key/value pairs encoded in user's favorite format. The format of the<br>
key-value pairs are not specified and remain opaque to Instr/Sample<br>
Profiler<br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
...<span class=""><br>
<br>
</span>I think all meta data should be custom defined -- the profile reader<br>
should not need to understand them.<span class=""><br></span></blockquote><div><br><br>OK. The benefit of enforcing some structure from the 
start is that it gives us the the possibility of machine parsing/round 
trip of the content for future applications. Initially this would just 
impact how we encode the label content - the reader classes could still 
treat the content as opaque for the time being if the 
format were something intended to be human-readable like YAML. On the 
other hand, if the metadata content begins life unstructured, it would be 
harder to retrofit structure later. <br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span><span class="">...<br>
><br>
> In terms of implementation, the metadata could live as a separate contiguous<br>
> section in the binary profile formats. It might make sense to encode it in<br>
> something like YAML so that it could also be directly embedded in the<br>
> various text formats.<br>
><br>
<br>
</span>A single string after the header should do.<br></blockquote><div><br>For the text formats I'd suggest that we delimit the label information with known prefix/suffix lines. That keeps it easy to parse (and skip) - especially since the label content can be multiple lines. The delimiters would only be a part of the file format and wouldn't be displayed from llvm-profdata.<br></div></div><br></div></div>