This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSOC 2018 - Textual LTO dump tool project


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


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
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]