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

[David Blaikie via llvm-dev]

On Mon, Jul 17, 2017 at 5:33 PM Teresa Johnson <tejohnson at google.com> wrote:

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

Great to hear!


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

What sort of timeline/high cost is involved with implementing the .ll
format? That's what I'm not sure I understand - usually .ll features are
added as a matter of course and don't seem to have been a major cost in
implementing new bitcode features so far as I know.

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 <(408)%20460-2413>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170719/c773a528/attachment.html>