http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54146
Richard Guenther <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |memory-hog
--- Comment #49 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-08-16
12:10:56 UTC ---
We still use very much memory (full testcase doesn't fit in 4GB ram). With
...
check<CGAL::Gmpfr>();
//check<CGAL::Gmpfi>();
//check<CGAL::Quotient<CGAL::Gmpz> >();
//check<CGAL::Lazy_exact_nt<CGAL::Gmpq> >();
//check<CORE::BigInt>();
//check<CORE::BigRat>();
//check<CORE::BigFloat>();
//check<CORE::Expr>();
I see (--enable-gather-detailed-mem-stats):
Kind Nodes Bytes
---------------------------------------
decls 1116380 181227400
types 535841 90021288
blocks 222522 17801760
stmts 45749 2068872
refs 854577 43178392
exprs 2147881 95117920
constants 140132 4176820
identifiers 73710 6486480
vecs 2654190 131466648
binfos 48162 4873432
ssa names 339369 27149520
constructors 26426 634224
random kinds 1885177 73894984
lang_decl kinds 352117 13918872
lang_type kinds 48218 7329136
omp clauses 0 0
---------------------------------------
Total 10490451 699345748
a lot of memory in TREE_VECs for some reason.
GIMPLE statements
Kind Stmts Bytes
---------------------------------------
assignments 316019 30602376
phi nodes 54994 15777472
conditionals 26090 2504640
everything else 237509 23110772
---------------------------------------
Total 634612 71995260
gimple is lean, so is RTL ;)
Alloc-pool Kind Elt size Pools Allocated (elts) Peak
(elts) Leak (elts)
--------------------------------------------------------------------------------------------------------------
live ranges 40 513 19250760( 481269) 10800800(
270020) 0( 0)
df_scan ref base 56 1026 331010008( 5910893) 14059808(
251068) 0( 0)
df_scan ref artificial 64 1026 20113600( 314275) 4239872(
66248) 0( 0)
df_scan ref regular 64 1026 66557568( 1039962) 4543872(
70998) 0( 0)
are by far the biggest alloc-pool users.
bitmap stats are confusing because they show leaks for bitmaps we free
by releasing their obstack. DF and PTA bitmaps are largest.
We leak some VECs ...
c-family/c-pragma.c:619 (push_visibility) 24: 0.0% 24
1: 0.0%
cp/pt.c:471 (maybe_begin_member_template_process 24: 0.0% 24
1: 0.0%
function.c:4513 (push_struct_function) 40: 0.0% 40
1: 0.0%
vec.c:307 (vec_stack_p_reserve_exact_1) 40: 0.0% 40
1: 0.0%
tree-ssa-loop-ivopts.c:3070 (multiplier_allowed_ 328: 0.0% 608
3: 0.0%
tree-ssa-loop-ivopts.c:3153 (get_address_cost) 328: 0.0% 608
3: 0.0%
tree-ssa-sccvn.c:745 (copy_reference_ops_from_re 392: 0.0% 806232
102098: 4.6%
cfgloop.h:583 (fel_init) 480: 0.0% 860
106: 0.0%
c-family/c-pragma.c:1246 (c_register_pragma_1) 584: 0.0% 696
4: 0.0%
function.c:156 (push_function_context) 976: 0.0% 1200
8: 0.0%
ira.c:3699 (find_moveable_pseudos) 1240: 0.0% 221128
513: 0.0%
passes.c:2188 (execute_one_pass) 4360: 0.1% 655320
16466: 0.7%
tree-ssa-structalias.c:3870 (handle_lhs_call) 9576: 0.2% 18360
133: 0.0%
ipa-ref.c:55 (ipa_record_reference) 60184: 1.1% 327640
5813: 0.3%
cfgloop.c:1143 (get_loop_exit_edges) 73184: 1.3% 157888
62221: 2.8%
tree-into-ssa.c:940 (mark_phi_for_rewrite) 153360: 2.7% 164096
17: 0.0%
cfgloop.c:1134 (get_loop_exit_edges) 166592: 3.0% 238712
11639: 0.5%
ipa-reference.c:184 (set_reference_optimization_ 180248: 3.2% 248064
47: 0.0%
tree-into-ssa.c:321 (get_ssa_name_ann) 627448:11.2% 716496
14: 0.0%
tree-ssa-sccvn.c:3657 (extract_and_process_scc_f 1246864:22.3% 1291960
105903: 4.7%
tree-ssa-loop-im.c:1562 (record_mem_ref_loc) 1292560:23.1% 1392576
55465: 2.5%
tree-ssa-loop-im.c:1551 (record_mem_ref_loc) 1771800:31.7% 3141360
52717: 2.4%
I'll look at the loop and sccvn parts.
