[llvm-dev] [PGO] Thoughts on adding a key-value store to profile data formats

[Nathan Slingerland via llvm-dev]

On Fri, Jan 15, 2016 at 11:41 AM, Xinliang David Li <davidxl at google.com>
wrote:

> Tagging profile data with such information is generally useful. My
> thoughts are
>
> 1) such information is probably not needed to be stored in raw format
> profile data -- so no runtime changes are needed -- only llvm-profdata
> and indexed format need to be enhanced to support this.
> 2) A more general way is just add an option:
> --embed_label=<customized_label>, where the label is a string can be
> key/value pairs encoded in user's favorite format. The format of the
> key-value pairs are not specified and remain opaque to Instr/Sample
> Profiler
>

...
>
> I think all meta data should be custom defined -- the profile reader
> should not need to understand them.
>


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.


> ...
> >
> > In terms of implementation, the metadata could live as a separate
> contiguous
> > section in the binary profile formats. It might make sense to encode it
> in
> > something like YAML so that it could also be directly embedded in the
> > various text formats.
> >
>
> A single string after the header should do.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160118/ee0beca6/attachment.html>