Rietveld Code Review Tool
Help | Bug tracker | Discussion group | Source code | Sign in
(291)

Issue 4921051: [pph] Fix x1dynarra1, x1dynarray2a and x1dynarray2b (Closed)

Can't Edit
Can't Publish+Mail
Start Review
Created:
12 years, 10 months ago by Diego Novillo
Modified:
12 years, 8 months ago
Reviewers:
CC:
Lawrence Crowl, Gabriel Charette, gcc-patches_gcc.gnu.org
Visibility:
Public.

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+23 lines, -10 lines) Patch
M gcc/cp/ChangeLog.pph View 1 chunk +9 lines, -0 lines 0 comments Download
M gcc/cp/pph-streamer-in.c View 1 chunk +1 line, -1 line 0 comments Download
M gcc/cp/pph-streamer-out.c View 2 chunks +4 lines, -2 lines 0 comments Download
M gcc/testsuite/ChangeLog.pph View 1 chunk +6 lines, -0 lines 0 comments Download
M gcc/testsuite/g++.dg/pph/x1dynarray1.cc View 1 chunk +1 line, -2 lines 0 comments Download
M gcc/testsuite/g++.dg/pph/x1dynarray2a.cc View 1 chunk +1 line, -2 lines 0 comments Download
M gcc/testsuite/g++.dg/pph/x1dynarray2b.cc View 1 chunk +1 line, -3 lines 0 comments Download

Messages

Total messages: 2
Diego Novillo
This patch fixes some template test cases. We were trying to expand functions that did ...
12 years, 10 months ago (2011-08-22 15:22:04 UTC) #1
Gabriel Charette
12 years, 10 months ago (2011-08-22 16:13:39 UTC) #2
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
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld f62528b