revised PATCH: CALL_EXPR representation changes, part 0/9 (table of contents)

[Sandra Loosemore]

Jan Hubicka wrote:

> comparing PR rtl-optimization/28071 testcase compilation at -O1 level:
>   Overall memory allocated via mmap and sbrk increased from 240608k to 246404k, overall 2.41%
>   Peak amount of GGC memory allocated before garbage collecting increased from 84342k to 85924k, overall 1.88%
>   Peak amount of GGC memory still allocated after garbage collecting increased from 73896k to 74852k, overall 1.29%
>   Amount of memory still referenced at the end of compilation increased from 19610k to 20861k, overall 6.38%
> 
> Perhaps little analysis would help.  Memory tester now publish stuff on
> webpage http://www.suse.de/~gcctest/memory/ and
> http://www.suse.de/~gcctest/memory/results (I just noticed I forgot to
> link from the main tester page) contains logs.
> 
> The logs in question are 
> http://www.suse.de/~gcctest/memory/results/200702160035/pr28071-O1.rep
> (from today)
> http://www.suse.de/~gcctest/memory/results/200702141642/pr28071-O1.rep
> (from day before patch was comitted)
> 
> At first glance one curious fact is that:
> stringpool.c:77 (alloc_node)                              0: 0.0% 0: 0.0%    6875024:34.2%     528848: 1.7%      66106
> ggc-common.c:193 (ggc_calloc)                       6470864: 2.8% 5000784: 8.6%    1761064: 8.8%    1068056: 3.4%        516
> changed to:
> stringpool.c:77 (alloc_node)                              0: 0.0% 0: 0.0%    7893912:37.0%     607224: 1.9%      75903
> ggc-common.c:193 (ggc_calloc)                       6733160: 2.9% 5000784: 8.6%    2023176: 9.5%    1068176: 3.4%        517
> 
> The ggc_calloc can be probably attributed to the vectors holding call
> expressions, but how can it came into increasing memory usage of
> stringpool from 6.8MB to 7.8MB?

Today I locally ran this memory profiling test comparing revision 122017 (the 
last one prior to the big CALL_EXPR hack check-in) to my local working copy 
(revision 122101 plus patches 
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01487.html and
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01584.html).

I've attached the -fmem-report output from compiling the bug2.c testcase at -O1. 
     I am seeing that the stringpool.c:77 output is showing 7.8MB in both 
versions, and the number of identifier nodes is also the same (75903) in both 
sets of output.  So maybe the regression you noted above was introduced in some 
change just before I committed the CALL_EXPR patch, and not in the CALL_EXPR 
patch itself?  My testing was done on x86_64-unknown-linux-gnu, if that matters.

BTW, you'll also see the effects of the CALL_EXPR hacking in these results.... 
about 10% fewer "random kinds" (TREE_LIST) nodes and about 3% fewer tree nodes 
overall.

-Sandra

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bug2.122017
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20070219/257dcd76/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bug2.sandra-feb18
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20070219/257dcd76/attachment-0001.ksh>