Jan Hubicka - Re: revised PATCH: CALL_EXPR representation changes, part 0/9 (table o (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.

• From: Jan Hubicka
• To: Sandra Loosemore
• Cc: Steven Bosscher , gcc-patches at gcc dot gnu dot org, Jan Hubicka , Ian Lance Taylor , java-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org, Brooks Moses , Lee Millward
• Date: Fri, 16 Feb 2007 20:11:00 +0100
• Subject: Re: revised PATCH: CALL_EXPR representation changes, part 0/9 (table of contents)
• References: <45D34986.5070401@codesourcery.com> <45D4F2FF.4030503@codesourcery.com> <20070216085053.GA11868@atrey.karlin.mff.cuni.cz> <200702161545.33828.steven@gcc.gnu.org> <45D5C7D1.2010809@codesourcery.com>

Steven Bosscher wrote:

On Friday 16 February 2007 09:50, Jan Hubicka wrote:

Hi, this is report from memory tester, overall it seems to be slight memory consumption increase. Are there any plans to get the memory back?

Sandra said in a mail last week that there is supposed to be a ~2% memory saving (http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00945.html). That is a number that should be visible in your measurements. Are you and Sandra measuring the same thing?

I expect that the current mainline version does show a memory use regression. As I mentioned in another e-mail, I have two additional patches from the LTO branch that I need to bring over to clobber some critical cases where temporary lists are being constructed. I will try to get to that today. Anyway, my measurements on the LTO branch were made with those two additional patches in place.

Hi, if the two additional patches will change memory usage, I will get mail from memory tester. However there are case where amount of memory after garbage collecting increase, this is definitly not attributable to temporary datastructures. I am particularly puzzled by the memory referenced at the end of compilation, in the case of PR28071 it is 6%:

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?

Honza

• Follow-Ups:
  • Re: revised PATCH: CALL_EXPR representation changes, part 0/9 (table of contents)
    * From: Sandra Loosemore
  • Re: revised PATCH: CALL_EXPR representation changes, part 0/9 (table of contents)
    * From: Sandra Loosemore
• References:
  • revised PATCH: CALL_EXPR representation changes, part 0/9 (table of contents)
    * From: Sandra Loosemore
  • Re: revised PATCH: CALL_EXPR representation changes, part 0/9 (table of contents)
    * From: Sandra Loosemore
  • Re: revised PATCH: CALL_EXPR representation changes, part 0/9 (table of contents)
    * From: Jan Hubicka
  • Re: revised PATCH: CALL_EXPR representation changes, part 0/9 (table of contents)
    * From: Steven Bosscher
  • Re: revised PATCH: CALL_EXPR representation changes, part 0/9 (table of contents)
    * From: Sandra Loosemore