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

[Mehdi AMINI via llvm-dev]

2017-06-05 7:54 GMT-07:00 Charles Saternos <charles.saternos at gmail.com>:

> 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?
>

Ideally I'd vote for both, I'd say it should be the default output if the
bitcode contains a summary.

-- 
Mehdi


>
> 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/a4dbfe50/attachment-0001.html>