public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: Richard Biener <richard.guenther@gmail.com>
Cc: "Hrishikesh Kulkarni" <hrishikeshparag@gmail.com>,
	"GCC Development" <gcc@gcc.gnu.org>,
	"Martin Liška" <mliska@suse.cz>,
	"Martin Jambor" <mjambor@suse.cz>
Subject: Re: GSOC 2018 - Textual LTO dump tool project
Date: Fri, 02 Mar 2018 13:01:00 -0000	[thread overview]
Message-ID: <20180302130120.GA21280@kam.mff.cuni.cz> (raw)
In-Reply-To: <CAFiYyc1VZ1Jr=g9MXwCmsjwwDAJT+n1pownjTjobNuZ_tneHDg@mail.gmail.com>

Hello,
> On Fri, Mar 2, 2018 at 10:24 AM, Hrishikesh Kulkarni
> <hrishikeshparag@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

  reply	other threads:[~2018-03-02 13:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-19  8:30 Hrishikesh Kulkarni
2018-02-25  9:47 ` Martin Jambor
2018-02-27 16:11   ` Richard Biener
2018-02-28 14:38   ` Martin Liška
2018-03-02  9:25     ` Hrishikesh Kulkarni
2018-03-02  9:48       ` Richard Biener
2018-03-02 13:01         ` Jan Hubicka [this message]
2018-03-06 13:30           ` Hrishikesh Kulkarni
2018-03-06 14:37             ` Richard Biener
2018-03-06 14:51               ` Jan Hubicka
2018-03-06 15:02               ` Jan Hubicka
2018-03-06 15:06                 ` Richard Biener
2018-03-06 15:29                   ` Jan Hubicka
2018-03-11 19:23                     ` Hrishikesh Kulkarni
2018-03-12 11:16                       ` Richard Biener
2018-03-13  4:30                         ` Hrishikesh Kulkarni
2018-03-14 14:58                           ` Richard Biener
2018-03-14 19:13                             ` Hrishikesh Kulkarni
2018-03-15  8:46                               ` Richard Biener
2018-03-15 10:39                                 ` Martin Liška
2018-03-16 13:44                                   ` Hrishikesh Kulkarni

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180302130120.GA21280@kam.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc@gcc.gnu.org \
    --cc=hrishikeshparag@gmail.com \
    --cc=mjambor@suse.cz \
    --cc=mliska@suse.cz \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).