> 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....
Well, because I think it would be good for us to more formalize our IL - document it properly, remove stuff which is not necessary and get an API+file representation. Those things are connected to each other and will need work. If you look how much things chage, it is not very frequent we would change what is in our CFG (I changed profile this release), how gimple tuples are represented and what gimple instructions we have. I think those parts are resonably well defined. Even if I changed profile this release it is relatively localized type of change. I am still more commonly changing symbol table as it needs to adapt for all LTO details, but I hope to be basically done. What is more on the go are trees that we will hopefully deal with by defining gimple types now with early debug done. What we can do realistically now is to first aim to stream those of better defined parts in externally parseable sections which do have documentation. So far only externally parseable section is the plugin symbol table, but we should be able to do so with reasonable effort for symbol tables, CFGs and gimple instruction streams. In parallel we can incrementally deal with trees mostly hopefully by getting rid of them (moving symbol names/etc to symbol table so it can live w/o declarations, having gimple types etc.) > > > 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 ...) > > > Thanks! > > > > > > I am trying to break down the project into milestones for the proposal. So > > far, I have identified the following objectives: > > > > 1] Creating a separate driver, that can read LTO object files. Following > > Richard’s estimate, I’d leave around first half of the period for this task. > > > > Would that be OK ? > > Yes. Yes, it looks good to me too. > > > Coming to 2nd half: > > > > 2] Dumping pass summaries. > > > > 3] Stabilizing lto-cgraph and symbol table. > > So I'd instead do > > 3] Enhance the user-interface of the driver > > like providing a way to list all function bodies, a way to dump > the IL of a single function body, a way to create a dot graph file > for the cgraph in the file, etc. > > Basically while there's a lot of dumping infrastructure in GCC > it may not always fit the needs of a LTO IL dumping tool 1:1 > and may need refactoring enhancement. I would agree here - dumping pass summaries would be nice but we already have that more or less. All IPA passes dump their summary into beggining of their dump file and I find that relatively sufficient to deal with mostly because summaries are quite simple. It is much harder to deal with the global sream of trees and function bodies themselves. Honza > > Richard. > > > > > Thanks, > > > > Hrishikesh > > > > > > > > On Fri, Mar 2, 2018 at 6:31 PM, Jan Hubicka <hubi...@ucw.cz> wrote: > >> > >> Hello, > >> > On Fri, Mar 2, 2018 at 10:24 AM, Hrishikesh Kulkarni > >> > <hrishikeshpa...@gmail.com> wrote: > >> > > Hello everyone, > >> > > > >> > > > >> > > Thanks for your suggestions and engaging response. > >> > > > >> > > Based on the feedback I think that the scope of this project comprises > >> > > of > >> > > following three indicative actions: > >> > > > >> > > > >> > > 1. Creating separate driver i.e. separate dump tool that uses lto > >> > > object API > >> > > for reading the lto file. > >> > > >> > Yes. I expect this will take the whole first half of the project, > >> > after this you > >> > should be somewhat familiar with the infrastructure as well. With the > >> > existing dumping infrastructure it should be possible to dump the > >> > callgraph and individual function bodies. > >> > > >> > > > >> > > 2. Extending LTO dump infrastructure: > >> > > > >> > > GCC already seems to have dump infrastructure for pretty-printing tree > >> > > nodes, gimple statements etc. However I suppose we’d need to extend > >> > > that for > >> > > dumping pass summaries ? For instance, should we add a new hook say > >> > > “dump” > >> > > to ipa_opt_pass_d that’d dump the pass > >> > > summary ? > >> > > >> > That sounds like a good idea indeed. I'm not sure if this is the most > >> > interesting > >> > missing part - I guess we'll find out once a dump tool is available. > >> > >> Concering the LTO file format my longer term aim is to make the symbol > >> table sections (symtab used by lto-plugin as well as the callgraph > >> section) > >> and hopefully also the Gimple streams) documented and well behaving > >> without changing the format in every revision. > >> > >> On the other hand the summaries used by individual passes are intended to > >> be > >> pass specific and envolving as individula passes become stronger/new > >> passes > >> are added. > >> > >> It is quite a lot of work to stabilize gimple representation to this > >> extend, > >> For callgraph&symbol table this is however more realistic. That would mean > >> to > >> move some of existing random stuff streamed there into summaries and > >> additionaly > >> cleaning up/rewriting lto-cgraph so the on disk format actually makes > >> sense. > >> > >> I will be happy to help with any steps in this direction as well. > >> > >> Honza > > > >
