[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