On Wed, Mar 14, 2018 at 8:13 PM, Hrishikesh Kulkarni <hrishikeshpa...@gmail.com> wrote: > Hi, > > Thanks a lot for inputs and guidance. I have incorporated all the changes in > the document. Shall I go ahead and submit the proposal formally on GSOC > website?
Yes, I think it's fine to submit it - but let's ask the Mentor for the project, Martin, for his opinion first. Martin? Thanks, Richard. > Drive link to Proposal: > https://docs.google.com/document/d/1-jYwwDWsHQwMaxVsHFBrJ9EiCAev7ljTDLS1xMwvK5w/edit > > Regards, > > Hrishikesh > > On Wed, Mar 14, 2018 at 8:28 PM, Richard Biener <richard.guent...@gmail.com> > wrote: >> >> On Tue, Mar 13, 2018 at 5:30 AM, Hrishikesh Kulkarni >> <hrishikeshpa...@gmail.com> wrote: >> > Hi, >> > >> > Thanks. I have tried to incorporate suggestions and prepared a revised >> > draft >> > of proposal for GSOC. Please find the same attached herewith. Your >> > suggestions in regard with this draft would definitely help me to >> > improve it >> > further for submission. >> >> Thanks, it looks very good now. You have essentially duplicated items >> in 1. and 2., namely --summary=<passname> and Dumping of IPA summaries. >> I would move some of the 1. items over to 2., apart from --summary I'd >> also >> move --cgraph-dot. >> >> Richard. >> >> > >> > Drive link to Draft Proposal: >> > >> > >> > https://docs.google.com/document/d/1-jYwwDWsHQwMaxVsHFBrJ9EiCAev7ljTDLS1xMwvK5w/edit >> > >> > >> > Regards, >> > >> > Hrishikesh >> > >> > >> > >> > >> > On Mon, Mar 12, 2018 at 4:45 PM, Richard Biener >> > <richard.guent...@gmail.com> >> > wrote: >> >> >> >> On Sun, Mar 11, 2018 at 8:23 PM, Hrishikesh Kulkarni >> >> <hrishikeshpa...@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 <hubi...@ucw.cz> wrote: >> >> >> >> >> >> > On Tue, Mar 6, 2018 at 4:02 PM, Jan Hubicka <hubi...@ucw.cz> >> >> >> > wrote: >> >> >> > >> On Tue, Mar 6, 2018 at 2:30 PM, Hrishikesh Kulkarni >> >> >> > >> <hrishikeshpa...@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 >> >> > >> >> > >> > >> > > >
