[llvm-dev] RFC: XRay in the LLVM Library

[Dean Michael Berris via llvm-dev]

> On 2 Dec. 2016, at 09:06, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> Not sure I quite follow here - perhaps some misunderstanding.
> 
> My mental model here is that the formats are semantically equivalent - with a common in-memory representation (like LLVM IR APIs). It doesn't/shouldn't complicate a comparison tool to support both LLVM IR and bitcode input (or some other hypothetical formats that are semantically equivalent that we could integrate into a common reading API). At least that's my mental model.
> 

I think you mean 'conversion' instead of 'comparison', but having said that we cannot assume that semantic equivalence implies "cheapness". At least in FDR mode, the way the data is laid out in the file will be one fixed-sized chunk per thread's log. These chunks may be interleaved with each other, forming something like the following:

[ File Header ] [ <thread 1 buffer>, <thread 2 buffer>, <thread 1 buffer>, ... ]

While this can be converted to the current "naive" format:

[ File Header ] [ <record>, <record>, <record>, ... ]

N.B. Where <record> is a self-contained tuple of (tsc, cpu id, thread id, record type, function id, padding).

The process of doing so will be very expensive -- i.e. we'll have to denormalise the records per thread-buffer, expand out the TSCs, potentially load the whole FDR trace in memory, have multiple passes, etc. While we can certainly make that part be implemented as a library so that we can "support" this alternate format/representation, I'm not sure we want users using the library to pay for this cost in terms of storage and processing time if all they really want is to deal with an XRay trace.

The proposal is to keep the complexity involved with converting the FDR log format into the naive log format (both are binary, either one can have YAML analogues) in the conversion tool but only really support one canonical format (the naive one which could either be in YAML or binary) for the library that deals with this format.

> Is there something different here?
> 
> What I'm picturing is that we need an API for reading all these formats and either we use that API only in the conversion tool - and users then have to run the conversion tool before running the tool they want. Or we sink that API into a common place, and all tools use that API to load inputs - making the user experience simpler (they don't have to run an extra conversion step/tool) but it doesn't seem like it should make the development experience more complicated/messy/difficult.
> 

I think having the complexity of conversion be localised in the tool may be better, than consolidating that API into something that others might be able to use outside of the tools. For instance, if we're talking about converting XRay traces to other supported formats (like CTF, the Chrome Trace Viewer supported format, or <insert something else>) then I suspect we want to keep that in the conversion tool's implementation rather than making those routines part of the distributed XRay library. Or if a user wanted to be able to read XRay traces in their application, they should just be able to support the canonical format, and the conversion happen externally to keep the costs low.

The trade-off I'm thinking of is in the support burden not only in the development of the tools, but also of the exposed library that defines what the supported formats of the XRay trace files look like. I suspect that iterating on a tool and gaining support for multiple formats there, and keeping a log reading library simple as a released library in LLVM strikes that balance of not needing to support too many formats in the API/Library, while being able to support many formats in the conversion tool.

I'd think of the analogy here as the conversion tool being clang that supports more than one programming language source code as input, but using a canonical LLVM IR representation (in-memory, or written out). While LLVM can handle backwards compatibility of the LLVM IR, it doesn't have to worry about clang supporting a new programming language.

Does that make sense?

-- Dean