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

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).

-- 
Mehdi



2017-06-02 20:36 GMT-07:00 Mehdi AMINI <joker.eph at gmail.com>:
>
>
> 2017-06-02 8:46 GMT-07:00 Charles Saternos via llvm-dev <
> llvm-dev at lists.llvm.org>:
>
>> Hey all,
>>
>> Below is the proposed format for the dump of the ThinLTO module summary
>> in the llvm-dis utility:
>>
>
> Our format are usually both way: you have to be able to parse them back.
>
>
>>
>> > ../build/bin/llvm-dis t.o && cat t.o.ll
>> ; ModuleID = '2.o'
>> source_filename = "2.ll"
>> target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
>> target triple = "x86_64-unknown-linux-gnu"
>>
>> @X = constant i32 42, section "foo", align 4
>>
>> @a = weak alias i32, i32* @X
>>
>> define void @afun() {
>>   %1 = load i32, i32* @a
>>   ret void
>> }
>>
>> define void @testtest() {
>>   tail call void @boop()
>>   ret void
>> }
>>
>> declare void @boop()
>>
>> ; Module summary:
>> ;  testtest (External linkage)
>> ;    Function (2 instructions)
>> ;    Calls: boop
>> ;  X (External linkage)
>> ;    Global Variable
>> ;  afun (External linkage)
>> ;    Function (2 instructions)
>> ;    Refs:
>> ;      a
>> ;  a (Weak any linkage)
>> ;    Alias (aliasee X)
>>
>> I've implemented the above format in the llvm-dis utility, since
there
>> currently isn't really a way of getting ThinLTO summaries in a
>> human-readable format.
>>
>
> What about the YAML serialization?
>
> --
> Mehdi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170602/e1faa990/attachment.html>

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

Teresa

> --
> Mehdi
>
>
>
> 2017-06-02 20:36 GMT-07:00 Mehdi AMINI <joker.eph at gmail.com>:
>
>>
>>
>> 2017-06-02 8:46 GMT-07:00 Charles Saternos via llvm-dev <
>> llvm-dev at lists.llvm.org>:
>>
>>> Hey all,
>>>
>>> Below is the proposed format for the dump of the ThinLTO module
summary
>>> in the llvm-dis utility:
>>>
>>
>> Our format are usually both way: you have to be able to parse them
back.
>>
>>
>>>
>>> > ../build/bin/llvm-dis t.o && cat t.o.ll
>>> ; ModuleID = '2.o'
>>> source_filename = "2.ll"
>>> target datalayout =
"e-m:e-i64:64-f80:128-n8:16:32:64-S128"
>>> target triple = "x86_64-unknown-linux-gnu"
>>>
>>> @X = constant i32 42, section "foo", align 4
>>>
>>> @a = weak alias i32, i32* @X
>>>
>>> define void @afun() {
>>>   %1 = load i32, i32* @a
>>>   ret void
>>> }
>>>
>>> define void @testtest() {
>>>   tail call void @boop()
>>>   ret void
>>> }
>>>
>>> declare void @boop()
>>>
>>> ; Module summary:
>>> ;  testtest (External linkage)
>>> ;    Function (2 instructions)
>>> ;    Calls: boop
>>> ;  X (External linkage)
>>> ;    Global Variable
>>> ;  afun (External linkage)
>>> ;    Function (2 instructions)
>>> ;    Refs:
>>> ;      a
>>> ;  a (Weak any linkage)
>>> ;    Alias (aliasee X)
>>>
>>> I've implemented the above format in the llvm-dis utility,
since there
>>> currently isn't really a way of getting ThinLTO summaries in a
>>> human-readable format.
>>>
>>
>> What about the YAML serialization?
>>
>> --
>> Mehdi
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>

-- 
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/20170603/5c6748e4/attachment-0001.html>

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>