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
