Teresa Johnson via llvm-dev
2017-Jun-02 19:49 UTC
[llvm-dev] [RFC][ThinLTO] llvm-dis ThinLTO summary dump format
On Fri, Jun 2, 2017 at 12:39 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:> On Fri, Jun 2, 2017 at 12:29 PM, Teresa Johnson <tejohnson at google.com> > wrote: > >> On Fri, Jun 2, 2017 at 12:18 PM, Peter Collingbourne via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> Why do we need a custom dumping format for the summary? Since we already >>> need the YAML format anyway, wouldn't it be better to extend that to cover >>> the entire summary? >>> >> >> IMO it is useful/convenient to be able to see the summary in the llvm-dis >> output. >> > > There are two things: > 1) the format of the summary > 2) where to add the dumper > I'm not too concerned about 2 (I wouldn't add it to llvm-dis, but rather > as a subcommand to llvm-lto2, but I don't have a strong opinion about that). > > So that leaves the text based summary format. We need a format that is > easily parseable so that we can test components that manipulate summaries > in isolation. That is what the YAML format is. Why add a second format that > is not parseable? >So in this case it is purely for visual inspection - I suggested that Charles add this as LLVM assembly comments, to make it clear that we can't currently reconstruct the summary if the LLVM assembly file is re-assembled (we currently need to rebuild the summary from scratch). I know you have added support for inputing the type id summaries in YAML form for testing purposes, since they were/are not being generated from IR during the current module summary index builder, but we have the opposite issue with the rest of the summaries (no serialization, but can build from IR). Teresa> Peter > > Teresa >> >> >>> Peter >>> >>> On Fri, Jun 2, 2017 at 8:46 AM, Charles Saternos via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> Hey all, >>>> >>>> Below is the proposed format for the dump of the ThinLTO module summary >>>> in the llvm-dis utility: >>>> >>>> > ../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. >>>> >>>> Let me know what you think of this format, and what information you >>>> think should be added/removed. >>>> >>>> Thanks, >>>> Charles >>>> >>>> >>>> _______________________________________________ >>>> LLVM Developers mailing list >>>> llvm-dev at lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>> >>>> >>> >>> >>> -- >>> -- >>> Peter >>> >>> _______________________________________________ >>> 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 <(408)%20460-2413> >> > > > > -- > -- > Peter >-- 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/20170602/d15c3e2b/attachment.html>
Peter Collingbourne via llvm-dev
2017-Jun-02 20:16 UTC
[llvm-dev] [RFC][ThinLTO] llvm-dis ThinLTO summary dump format
On Fri, Jun 2, 2017 at 12:49 PM, Teresa Johnson <tejohnson at google.com> wrote:> > > On Fri, Jun 2, 2017 at 12:39 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > >> On Fri, Jun 2, 2017 at 12:29 PM, Teresa Johnson <tejohnson at google.com> >> wrote: >> >>> On Fri, Jun 2, 2017 at 12:18 PM, Peter Collingbourne via llvm-dev < >>> llvm-dev at lists.llvm.org> wrote: >>> >>>> Why do we need a custom dumping format for the summary? Since we >>>> already need the YAML format anyway, wouldn't it be better to extend that >>>> to cover the entire summary? >>>> >>> >>> IMO it is useful/convenient to be able to see the summary in the >>> llvm-dis output. >>> >> >> There are two things: >> 1) the format of the summary >> 2) where to add the dumper >> I'm not too concerned about 2 (I wouldn't add it to llvm-dis, but rather >> as a subcommand to llvm-lto2, but I don't have a strong opinion about that). >> >> So that leaves the text based summary format. We need a format that is >> easily parseable so that we can test components that manipulate summaries >> in isolation. That is what the YAML format is. Why add a second format that >> is not parseable? >> > > So in this case it is purely for visual inspection - I suggested that > Charles add this as LLVM assembly comments, to make it clear that we can't > currently reconstruct the summary if the LLVM assembly file is re-assembled > (we currently need to rebuild the summary from scratch). I know you have > added support for inputing the type id summaries in YAML form for testing > purposes, since they were/are not being generated from IR during the > current module summary index builder, but we have the opposite issue with > the rest of the summaries (no serialization, but can build from IR). >Again: we could address that issue by adding the rest of the summary to the YAML serialization, no? I don't want to have to update the tests and the YAML dumper and the new-format dumper when I make a change to the summary format. Peter> > Teresa > > >> Peter >> >> Teresa >>> >>> >>>> Peter >>>> >>>> On Fri, Jun 2, 2017 at 8:46 AM, Charles Saternos via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>> Hey all, >>>>> >>>>> Below is the proposed format for the dump of the ThinLTO module >>>>> summary in the llvm-dis utility: >>>>> >>>>> > ../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. >>>>> >>>>> Let me know what you think of this format, and what information you >>>>> think should be added/removed. >>>>> >>>>> Thanks, >>>>> Charles >>>>> >>>>> >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> -- >>>> Peter >>>> >>>> _______________________________________________ >>>> 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 <(408)%20460-2413> >>> >> >> >> >> -- >> -- >> Peter >> > > > > -- > Teresa Johnson | Software Engineer | tejohnson at google.com | > 408-460-2413 <(408)%20460-2413> >-- -- Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170602/9d0dd89d/attachment-0001.html>
Teresa Johnson via llvm-dev
2017-Jun-02 20:51 UTC
[llvm-dev] [RFC][ThinLTO] llvm-dis ThinLTO summary dump format
On Fri, Jun 2, 2017 at 1:16 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:> On Fri, Jun 2, 2017 at 12:49 PM, Teresa Johnson <tejohnson at google.com> > wrote: > >> >> >> On Fri, Jun 2, 2017 at 12:39 PM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Fri, Jun 2, 2017 at 12:29 PM, Teresa Johnson <tejohnson at google.com> >>> wrote: >>> >>>> On Fri, Jun 2, 2017 at 12:18 PM, Peter Collingbourne via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>> Why do we need a custom dumping format for the summary? Since we >>>>> already need the YAML format anyway, wouldn't it be better to extend that >>>>> to cover the entire summary? >>>>> >>>> >>>> IMO it is useful/convenient to be able to see the summary in the >>>> llvm-dis output. >>>> >>> >>> There are two things: >>> 1) the format of the summary >>> 2) where to add the dumper >>> I'm not too concerned about 2 (I wouldn't add it to llvm-dis, but rather >>> as a subcommand to llvm-lto2, but I don't have a strong opinion about that). >>> >>> So that leaves the text based summary format. We need a format that is >>> easily parseable so that we can test components that manipulate summaries >>> in isolation. That is what the YAML format is. Why add a second format that >>> is not parseable? >>> >> >> So in this case it is purely for visual inspection - I suggested that >> Charles add this as LLVM assembly comments, to make it clear that we can't >> currently reconstruct the summary if the LLVM assembly file is re-assembled >> (we currently need to rebuild the summary from scratch). I know you have >> added support for inputing the type id summaries in YAML form for testing >> purposes, since they were/are not being generated from IR during the >> current module summary index builder, but we have the opposite issue with >> the rest of the summaries (no serialization, but can build from IR). >> > > Again: we could address that issue by adding the rest of the summary to > the YAML serialization, no? I don't want to have to update the tests and > the YAML dumper and the new-format dumper when I make a change to the > summary format. >What is the option for emitting the summary in YAML (I know it is incomplete, but just so we can see what it currently looks like)? Where does it get emitted? Teresa> > Peter > > >> >> Teresa >> >> >>> Peter >>> >>> Teresa >>>> >>>> >>>>> Peter >>>>> >>>>> On Fri, Jun 2, 2017 at 8:46 AM, Charles Saternos via llvm-dev < >>>>> llvm-dev at lists.llvm.org> wrote: >>>>> >>>>>> Hey all, >>>>>> >>>>>> Below is the proposed format for the dump of the ThinLTO module >>>>>> summary in the llvm-dis utility: >>>>>> >>>>>> > ../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. >>>>>> >>>>>> Let me know what you think of this format, and what information you >>>>>> think should be added/removed. >>>>>> >>>>>> Thanks, >>>>>> Charles >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> LLVM Developers mailing list >>>>>> llvm-dev at lists.llvm.org >>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> -- >>>>> Peter >>>>> >>>>> _______________________________________________ >>>>> 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 <(408)%20460-2413> >>>> >>> >>> >>> >>> -- >>> -- >>> Peter >>> >> >> >> >> -- >> Teresa Johnson | Software Engineer | tejohnson at google.com | >> 408-460-2413 <(408)%20460-2413> >> > > > > -- > -- > Peter >-- 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/20170602/8efb25c7/attachment.html>