This is the mail archive of the
mailing list for the GCC project.
Re: Save 6% of GGC memory (consumed in tree-ssa-pre)
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Jan Hubicka <jh at suse dot cz>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 02 Aug 2006 00:54:07 -0400
- Subject: Re: Save 6% of GGC memory (consumed in tree-ssa-pre)
- References: <20060731224556.GI3390@kam.mff.cuni.cz> <44CEB72B.firstname.lastname@example.org> <20060801121851.GD16158@kam.mff.cuni.cz>
Jan Hubicka wrote:
>> Jan Hubicka wrote:
>>> memory statistics for combine.c at -O2 shows 13% of memory to be taken
>>> by create_tree_ann function:
>>> tree-phinodes.c:156 (allocate_phi_node) 3813160: 4.6% 0: 0.0% 0: 0.0% 22568: 0.3% 12114
>>> genrtl.c:17 (gen_rtx_fmt_ee) 7518920: 9.1% 0: 0.0% 3080: 0.0% 1504400:17.1% 188050
>>> tree-dfa.c:209 (create_tree_ann) 10927080:13.3% 0: 0.0% 7440: 0.1% 728968: 8.3% 91121
>>> Total 82223861 12694004 6318427 8805836 1369076
>>> This is the same for my now favorite testcase and other common sources.
>>> I always accounted it to annotations being bloated, but I unstrumented
>>> create_tree_ann for statistics and found out that this all memory is in
>>> fact allocated all by tree-vn and it is all there just to hold one
>>> pointer value_handle. I would say that a hashtable would do a lot
>>> better job here (or direct use of the annotation pointer on
>>> expressions), but I am leaving it for Danny
>> If you use a hashtable, your PRE times will jump about 4 or 5x (my
>> recollection but feel free to try it yourself :) )
>> It makes *very* heavy use of getting the value handle, and it can't
>> really be avoided.
> not sure if it is best way around, but this patch saves about 50% of the
> allocated annotations on combine.c (4688760 instead of 10927080) and if
> PRE is really so annotation heavy, it should also save some compilation
> time (as would do inlining get_value_handle probably?).
In the pre speedup patch i sent you, i inlined get_value_handle.
> What do you think?
I dunno, i'm not a fan of pointer munging :)
In the new world order, all the expressions are going to have
annotations anyway, because i needed a unique id across all expressions
types (ssa_names, binary/unary/etc) to remove value sets (and achieve
the original speedup i sent you in a sane way).