Jan Hubicka - Re: revised PATCH: CALL_EXPR representation changes, part 0/9 (table (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: Jan Hubicka , Steven Bosscher , gcc-patches at gcc dot gnu dot org, Ian Lance Taylor , java-patches at gcc dot gnu dot org, fortran at gcc dot gnu dot org, Brooks Moses , Lee Millward
• Date: Tue, 20 Feb 2007 00:09:28 +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> <20070216191100.GB11868@atrey.karlin.mff.cuni.cz> <45D93344.2090800@codesourcery.com>

Hi,

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.

Indeed it looks like this was caused by different patch. My apologizes for the false alarm (and I will fix the webpage to point to correct bug2.c source, I was just mostly offline last few days). The situation is bit curious since the patch that changed stringpool itself must not've caused any noticable difference otherwise memory tester would send a mail too.

One thing I find curious still is tree-vn usage:

tree-vn.c:69 (make_value_handle) 3605256: 1.6% 0: 0.0% 0: 0.0% 400584: 1.3% 50073 to: tree-vn.c:69 (make_value_handle) 3738816: 1.6% 0: 0.0% 0: 0.0% 415424: 1.3% 51928

I don't see directly how your patch can affect number of value nodes, but it might be just some instability of optimizers. The overal memory consumption growth from 228MB to 230MB seems more in bound and I guess if the temporary list is created for every call in calls.c, it will be easilly fixed by your proposed patch. The testcase produces very large number of calls.

Honza

• Follow-Ups:
  • 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
  • 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: Sandra Loosemore