public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Gabriel Charette <gchare@google.com>
To: Diego Novillo <dnovillo@google.com>
Cc: reply@codereview.appspotmail.com, crowl@google.com,
	       gcc-patches@gcc.gnu.org
Subject: Re: [pph] Fix x1dynarra1, x1dynarray2a and x1dynarray2b (issue4921051)
Date: Mon, 22 Aug 2011 17:18:00 -0000	[thread overview]
Message-ID: <CAJTZ7LKK+ywaT4hn6bnujrpmPNsS0i7BP1G+pVb+nP_21pU2eg@mail.gmail.com> (raw)
In-Reply-To: <20110822152200.59EA41DA1CF@topo.tor.corp.google.com>

On Mon, Aug 22, 2011 at 8:22 AM, Diego Novillo <dnovillo@google.com> wrote:
>
> This patch fixes some template test cases.  We were trying to
> expand functions that did not really need expanding (templates).  This
> got me thinking that we are not approaching the expansion properly.
>
> We are trying to re-create all the cgraph creation done during the
> compilation of the header file.  Rather than re-creating all this, it
> would be more efficient to save the state of the callgraph and varpool
> at the time of pph generation and then simply recreate it at read
> time.  I will experiment with that, see if it actually makes any
> sense.
>

I had this idea earlier when playing with varpool for functions not
being streamed with their "rest_of_decl"compilation" state. The
problem for doing this if I remember correctly is that calling the
functions which generate those creates some unique ordering and IDs,
so that we need to do it in order of the current include order of each
pph in the current TU, and since the order of each pph in a given
compilation is not set ahead of time, I'm not sure this is possible
(at least not simple). We could probably find a way to merge those
states on the way in, but that would most likely tie us to the
implementation of those calls..

Gab

      reply	other threads:[~2011-08-22 16:13 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-22 15:50 Diego Novillo
2011-08-22 17:18 ` Gabriel Charette [this message]

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=CAJTZ7LKK+ywaT4hn6bnujrpmPNsS0i7BP1G+pVb+nP_21pU2eg@mail.gmail.com \
    --to=gchare@google.com \
    --cc=crowl@google.com \
    --cc=dnovillo@google.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=reply@codereview.appspotmail.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).