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

[David Blaikie 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).
>

What's the rough expectation of time/complexity for this path forward?


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

I'm not sure I understand why the tradeoff is worthwhile - in terms of
needing to add a new feature (even if it's already implemented) and tests,
then porting those tests to a first-class .ll construct later. Usually
adding .ll formats doesn't seem to be terribly expensive/time intensive.


> Making it available through the llvm-lto tool is a no-brainer to me.
>
> 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).
>

Not sure I quite follow why that difference made the choice/tradeoff here
different (which admittedly is a bit easier to see in retrospect maybe -
now that there's been a need to build serialization and deserialization).
Do you mean it wasn't clear that serialization support was needed when
summaries were first implemented, but it is clear now?

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170719/213af952/attachment.html>