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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Save 6% of GGC memory (consumed in tree-ssa-pre)


Jan Hubicka wrote:
>> Jan Hubicka wrote:
>>> Hi,
>>> 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.
> Hmm,
> 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).

--Dan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]