This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GSOC 2018 - Textual LTO dump tool project
On Sun, Mar 11, 2018 at 8:23 PM, Hrishikesh Kulkarni
<hrishikeshparag@gmail.com> wrote:
> Hi,
>
> Greetings! Please find my draft proposal for GSOC attached herewith. I am
> very grateful to all of you for your inputs, suggestions and directions. I
> have tried to assimilate these inputs received from you to convert it into a
> proposal. Your suggestions in regard with this draft would definitely help
> me to convert it into final proposal for submission. In addition, could you
> please suggest the possible extensions those can be added to dump tool?
>
>
> Drive link to Draft Proposal:
>
> https://docs.google.com/document/d/1-jYwwDWsHQwMaxVsHFBrJ9EiCAev7ljTDLS1xMwvK5w/edit
The proposal looks a bit sparse when giving details about the actual project.
I'd suggest to clarify at least the deliverables. I suggest for 1. add a 1 c)
that specifies what should be working, for example
lto-dump -l
should dump a list of variables and functions contained in the IL
lto-sump -s <id>
should dump detailed info about the symbol <id> (using the symtab dump
infrastructure)
lto-dump -f <id>
should dump the function body of the function with <id> (using the gimple
dump infrastructure)
the lto-dump tool should be verified to work on both WPA-time and LTRANS-time
objects.
Thus your 2) a) should be possible with 1) already. 2) would then contain
dumping of IPA summaries as major part apart from visualizing the callgraph.
For visualizing the (full) callgraph you need to handle multiple LTO
IL input files.
Those two pieces should be enough for 2) unless usability issues spill over
from 1).
In the introduction I miss some general words about the LTO IL, like that it
is non-self-describing bytecode which is documented only by the code
reading/writing it and thus hard to debug. It also misses to lay out the
overall structure of a LTO IL file (you are already going into detail with
IPA passes so this missing stands out).
Richard.
>
> Regards,
>
> Hrishikesh
>
>
>
> On Tue, Mar 6, 2018 at 8:59 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>
>> > On Tue, Mar 6, 2018 at 4:02 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > >> On Tue, Mar 6, 2018 at 2:30 PM, Hrishikesh Kulkarni
>> > >> <hrishikeshparag@gmail.com> wrote:
>> > >> > Hi,
>> > >> >
>> > >> > Thank you Richard and Honza for the suggestions. If I understand
>> > >> > correctly,
>> > >> > the issue is that LTO file format keeps changing per compiler
>> > >> > versions, so
>> > >> > we need a more “stable” representation and the first step for that
>> > >> > would be
>> > >> > to “stabilize” representations for lto-cgraph and symbol table ?
>> > >>
>> > >> Yes. Note the issue is that the current format is a 1:1
>> > >> representation of
>> > >> the internal representation -- which means it is the internal
>> > >> representation
>> > >> that changes frequently across releases. I'm not sure how Honza
>> > >> wants
>> > >> to deal with those changes in the context of a "stable" IL format.
>> > >> Given
>> > >> we haven't been able to provide a stable API to plugins I think it's
>> > >> much
>> > >> harder to provide a stable streaming format for all the IL
>> > >> details....
>> > >>
>> > >> > Could you
>> > >> > please elaborate on what initial steps need to be taken in this
>> > >> > regard, and
>> > >> > if it’s feasible within GSoC timeframe ?
>> > >>
>> > >> I don't think it is feasible in the GSoC timeframe (nor do I think
>> > >> it's feasible
>> > >> at all ...)
>> > >
>> > > I skipped this, with GSoC timeframe I fully agree. With feasibility
>> > > at all not so
>> > > much - LLVM documents its bitcode to reasonable extend
>> > > https://llvm.org/docs/BitCodeFormat.html
>> > >
>> > > Reason why i mentioned it is that I would like to use this as an
>> > > excuse to get
>> > > things incrementally cleaned up and it would be nice to keep it in
>> > > mind while
>> > > working on this.
>> >
>> > Ok. It's probably close enough to what I recommended doing with respect
>> > to make the LTO bytecode "self-descriptive" -- thus start with making
>> > the
>> > structure documented and parseable without assigning semantics to
>> > every bit ;) I think that can be achieved top-down in a very
>> > incremental
>> > way if you get the bottom implemented first (the data-streamer part).
>>
>> OK :)
>> I did not mean to document every bit either, at least not for the fancy
>> parts.
>> It would be nice to have clenned up i.e. the section headers/footers so
>> they
>> do not depend on endianity and slowly cleanup similar nonsences at higher
>> levels. So it may make sense to progress from both directions lower
>> hanging
>> fruits first.
>>
>> Honza
>
>