This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [pph] Fix x1dynarra1, x1dynarray2a and x1dynarray2b (issue4921051)
- From: Gabriel Charette <gchare at google dot com>
- To: Diego Novillo <dnovillo at google dot com>
- Cc: reply at codereview dot appspotmail dot com, crowl at google dot com, gcc-patches at gcc dot gnu dot org
- Date: Mon, 22 Aug 2011 09:13:36 -0700
- Subject: Re: [pph] Fix x1dynarra1, x1dynarray2a and x1dynarray2b (issue4921051)
- References: <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