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

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>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170605/3b3cc8ec/attachment.html>

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>