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

[Charles Saternos via llvm-dev]

Hey Teresa,

Yep, I can do that - I'll be clear in the output of the command that it's
just dumping for now and not meant for piping back into llvm-as. Do you
want this code in llvm-dis or llvm-lto2?

Thanks,
Charles

On Mon, Jun 5, 2017 at 10:13 AM, Teresa Johnson <tejohnson at google.com>
wrote:

>
>
> On Sat, Jun 3, 2017 at 8:58 AM, Mehdi AMINI <joker.eph at gmail.com> wrote:
>
>>
>> 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 :)
>>
>
> It's coherent with the first part, not necessarily with piping into
> llvm-as and not losing information (which would be a good follow-on, but
> let's get the dumping part at least for now).
>
> 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?
>>
>
> Yes.
>
> Charles - can you take a look at extending the existing YAML summary
> dumper to do this? See pcc's patch on one of the emails here for how to
> output that, but let's see if we can get that optionally into the llvm-dis
> output as comments for now.
>
> Looks like the existing YAML output dumps value ids, but as we discussed
> in our other thread, it would be good to map those to the value names and
> emit the value names instead.
>
> Teresa
>
>
>> --
>> Mehdi
>>
>>
>
>
> --
> Teresa Johnson |  Software Engineer |  tejohnson at google.com |
> 408-460-2413 <(408)%20460-2413>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170605/0fcd3817/attachment.html>