public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Guenther <richard.guenther@gmail.com>
To: Basile Starynkevitch <basile@starynkevitch.net>
Cc: gcc@gcc.gnu.org
Subject: Re: Serializing mixed gimple data from a plugin in LTO?
Date: Fri, 25 Mar 2011 10:13:00 -0000	[thread overview]
Message-ID: <AANLkTikB2FseW_-JbBPq4SC_R-qE3wnX6Ek=nKmuVmj+@mail.gmail.com> (raw)
In-Reply-To: <20110325083753.c2be7958.basile@starynkevitch.net>

On Fri, Mar 25, 2011 at 8:37 AM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> Hello All,
>
> Let's imagine someone is writing a plugin (or a MELT extension...) which computes some complex information around gimple in a pass before LTO serialization and re-uses that information in a later pass after LTO serialization. A possible way to associate data inside a plugin to some gimples would be to have hash tables (keys being Gimple, associated value being some complex information specific to the plugin). The the plugin would compute & serialize [i.e. write or output] data in a pass before LTO and deserialize [re-read or input] that data at LTO time.
>
> The writing happens in the write_summary and write_optimization_summary hooks of struct ipa_opt_pass_d of file tree-pass.h. The reading happens in read_summary & read_optimization_summary hooks.
>
> But what I cannot understand is how can such a plugin know what are the gimple involved. Since the plugin needs to persist (i.e. serialize into LTO stream & de-serialize) an hash table mapping some gimples to its data, the plugin need to know what gimples are serialized & deserialized, to restore at LTO streaming read the common gimple pointers (the same gimple pointer should appear in the function & the hash table)....
>
> I would imagine gcc/lto-streamer-out.c would have a plugin hook inside output_gimple_stmt but this is not the case...
>
> I admit I don't have a clear picture of LTO streams usage (& customization) from plugins.
> Or perhaps it is not possible yet???

You are not allowed to piggy-back on statements but only global things
like cgraph and varpool.  There is no way to transition data from before
LTO to after associated with statements.  And there never will be.

Richard.

> Regards.
> --
> Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
> email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mine, sont seulement les miennes} ***
>

  reply	other threads:[~2011-03-25 10:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-25 10:07 Basile Starynkevitch
2011-03-25 10:13 ` Richard Guenther [this message]
2011-03-25 12:01   ` Diego Novillo
2011-03-25 12:17     ` Richard Guenther

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='AANLkTikB2FseW_-JbBPq4SC_R-qE3wnX6Ek=nKmuVmj+@mail.gmail.com' \
    --to=richard.guenther@gmail.com \
    --cc=basile@starynkevitch.net \
    --cc=gcc@gcc.gnu.org \
    /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).