> 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
