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 ? Could you please elaborate on what initial steps need to be taken in this regard, and if it’s feasible within GSoC timeframe ?
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 ? Coming to 2nd half: 2] Dumping pass summaries. 3] Stabilizing lto-cgraph and symbol table. 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 >
