[llvm-dev] [RFC][ThinLTO] llvm-dis ThinLTO summary dump format

[Mehdi AMINI via llvm-dev]

On Sat, Jun 3, 2017 at 8:33 AM Teresa Johnson <tejohnson at google.com> wrote:

> On Fri, Jun 2, 2017 at 8:41 PM, Mehdi AMINI via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Oh I just see that there were already a bunch of answers. I missed the
>> thread, sorry.
>>
>> So basically my intuitive approach on this is close to what I perceive
>> Peter's position is:
>>
>> - don't create a new format if there is already one.
>> - if you really have a good reason to create a new format, it should
>> replace the existing one (i.e. don't maintain two).
>> - ideally we should be able to pipe the output if llvm-dis to llvm-as in
>> a lossless manner (if our layering requires to use another tool than
>> llvm-as, so be it).
>>
>
> I don't disagree with these points. I was the one who suggested that
> Charles implement this as a learning experience for his ThinLTO GSoC
> project, because I have long wanted a simple human-readable dumper for the
> summaries. I knew about the YAML support Peter added for the type test
> summaries, but thought that was largely geared towards testing while those
> summaries weren't automatically generated from the IR. It sounds reasonable
> to have a single format, and so doing the dumping with YAML seems fine to
> me. However, I would prefer to have a way to dump that into the llvm
> disassembly with llvm-dis.
>

That's coherent with the part where I wrote that `llvm-dis | llvm-as`
should not lose information :)
So can't we achieve this goal by appending the YAML format to the output of
llvm-dis? (and teach llvm-as to recognize it?)


I'd personally put a higher priority on getting the dumping functionality
> out first and faster (e.g. emitting as comments in the disassembly to
> indicate that it is dump only for now), and deal with regenerating the
> summary from it during llvm-as later.
>

If it is non-trivial to adapt llvm-as, then sure: but you could also have
the YAML format printed in a comment which should allow this right?

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170603/767adc6d/attachment.html>