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

Issue 5139052: [pph] Prepare for mutation detection [3/3] (Closed)

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

Patch Set 1 #

Unified diffs Side-by-side diffs Delta from patch set Stats (+165 lines, -69 lines) Patch
M gcc/cp/ChangeLog.pph View 1 chunk +18 lines, -0 lines 0 comments Download
M gcc/cp/pph-streamer.h View 2 chunks +5 lines, -1 line 0 comments Download
M gcc/cp/pph-streamer.c View 1 chunk +0 lines, -2 lines 0 comments Download
M gcc/cp/pph-streamer-in.c View 1 chunk +0 lines, -1 line 0 comments Download
M gcc/cp/pph-streamer-out.c View 19 chunks +142 lines, -65 lines 0 comments Download

Messages

Total messages: 3
Diego Novillo
This finishes removing constants and builtins out of the cache. This time in a slightly ...
12 years, 7 months ago (2011-09-27 17:03:08 UTC) #1
gcharette1
Very nice! I really like where this is heading :)! I think it would be ...
12 years, 7 months ago (2011-09-28 21:28:36 UTC) #2
Diego Novillo
12 years, 7 months ago (2011-10-04 15:15:18 UTC) #3
On Wed, Sep 28, 2011 at 17:28, Gabriel Charette <gcharette1@gmail.com> wrote:
> Very nice!
>
> I really like where this is heading :)!
>
> I think it would be great to instrument this to know how many times we
> need to use a PPH_RECORD_MREF, to avoid trashing the cache (i.e.
> potentially there are specific cases where only a small field's value
> changes and pickling the entire tree again is sub-optimal; if instead
> we could detect those cases and simply output the required change
> which could then be applied on the reader side it would potentially be
> better... it is possible that we haven't been affected by these
> specific cases up until now, but that they would all massively result
> in PPH_RECORD_MREFs now (the instrumentation would also potentially
> help us find some of those tricky mutation, if there are any caused by
> other things than overloads, which we aren't aware of yet...just a
> thought).

Yes, that's in the backburner, but I will wait until we have a more
complete implementation to start looking into these optimizations.

One thing that is very easy to do is to only try to handle mutations
of shared trees (tree_node_can_be_shared). Those are the only trees we
should even bother putting in the cache.


Diego.
Sign in to reply to this message.

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