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

[Teresa Johnson via llvm-dev]

On Mon, Jul 17, 2017 at 5:18 PM, Mehdi AMINI <joker.eph at gmail.com> wrote:

>
>
> 2017-07-17 16:49 GMT-07:00 David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org>:
>
>>
>>
>> On Mon, Jul 17, 2017 at 6:11 AM Charles Saternos via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>>> Hey @chandlerc and @dblaikie,
>>>
>>> Any updates on this in relation to "[PATCH] D34080: [ThinLTO] Add
>>> dump-summary command to llvm-lto2 tool"?
>>>
>>
>> Sorry you've kind of got stuck in the middle of this - but I'm still
>> hoping to hear/understand the pushback on implementing this as a first
>> class .ll construct with serialization and deserialization support.
>>
>> I think Peter mentioned he didn't think this was the right path forward
>> in the long term? If that's the case, I'd like to understand that/reach
>> that conclusion for the project now rather than treating this as a stop-gap
>> with some idea that in the future someone might implement full
>> serialization support (when it's been over a year already, and other stop
>> gaps have been implemented (the yaml input support) already).
>>
>
> I'm totally believing we need first class serialization support in .ll,
> and I have a path forward for this (just not a lot of time to dedicate to
> this).
>
>
>> & if a .ll construct with serialization/deserialization is the path
>> forward, understanding the motivation for a something other than going
>> straight for that would be helpful -usually bitcode features come with .ll
>> support from day 1, not a year later. I'm not clear on what would make this
>> feature an exception/more expensive to do this for (& why it would be worth
>> deferring that work, and what/when that work will be motivated/done)
>>
>
>
> We need a debugging tool for summaries ASAP, and the YAML is *already*
> implemented. Making it available through the llvm-lto tool is a no-brainer
> to me.
>

I will add that using Charles' patches to dump the summary with YAML was
invaluable in tracking down a bug recently.  Much easier than trying to
decode the llvm-bcanalyzer output. It would be great to get those in now,
as Mehdi notes there is already some existing YAML summary support, and I
do believe it is going to take some time to get serialization through the
.ll file defined and implemented (I know I don't have bandwidth at the
moment).


>
> This was *not* an oversight but a deliberate choice to not do this in the
> first place. Because summaries are the first bitcode feature I know of that
> isn't attached in any way to a Module (you can't get to it from a Module).
>

And because the summaries are computed from the IR.

But I don't disagree that it would be good to have serialization in/out of
.ll files, if only for debugging and testing purposes.

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/20170717/d82e8b94/attachment.html>