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

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 17 17:18:26 PDT 2017


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.

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

-- 
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170717/bc68b12b/attachment.html>


More information about the llvm-dev mailing list