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

[Jan Hubicka <hubicka at ucw dot cz>]

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