[PATCH] D21987: [XRay] Implement `llvm-xray extract`, start of the llvm-xray tool

[Dean Michael Berris via llvm-commits]

On Tue, Sep 13, 2016 at 10:48 AM David Blaikie <dblaikie at gmail.com> wrote:

> On Mon, Sep 12, 2016 at 5:43 PM Dean Michael Berris <dberris at google.com>
> wrote:
>
> On Tue, Sep 13, 2016 at 2:43 AM David Blaikie <dblaikie at gmail.com> wrote:
>
>
> I think the concern of whether the writing tool can be run correctly
> across platform is something to resolve first. I expect test cases for the
> tool to involve checked in binaries and executed on all test configurations
> in LLVM. It's just a tool reading a file and producing another file or the
> stats, etc.
>
>
> With the changes lined up after this one, we don't need to check in
> binaries -- we can write the log files in YAML and have them converted to
> particular targets, when we support them.
>
>
> OK, but the functionality would still be missing - in the sense that one
> couldn't take a file from one machine to another, then run the tool on it.
> I think that's, imho (others may fairly disagree - happy to chat more with
> Eric & Chandler, for example), a blocker. The tool should be able to read
> the file no matter which host we're on.
>

I think this is exactly what I meant -- that since this is a reciprocal
feature (writing/reading) then it will imply that we can convert from
whatever binary format from whatever platform to YAML and back. We just
have to test those. :)


>
>
> Not only then can we read them in a platform-specific format we can write
> them in that format too. Might be a little more work, but the choice here
> is doing that versus using Flatbuffers (i.e. being more clever about it).
>
>
> Not entirely following - but you're suggesting that portable reading of
> these splatted files is not practical, or at least it would be enough work
> that we might as well just do Flatbuffers from the get-go?
>
>

I'm suggesting that the amount of work will practically be the same in the
case of 2 or 3 platforms -- any more and then Flatbuffers would be a better
(albeit more expensive) approach. That we should do it when we have more
platforms supported.

Cheers

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160914/82dee4fc/attachment.html>