From: Jan Hubicka <jh@suse.cz>
To: gcc@gcc.gnu.org, law@redhat.com, amacleod@redhat.com
Subject: Varray memory consumption strikes back
Date: Sat, 04 Sep 2004 09:59:00 -0000 [thread overview]
Message-ID: <20040904095915.GV1947@kam.mff.cuni.cz> (raw)
Jeff,
In January I was concerned about memory consumption:
> I am somewhat concerned about use of varrays in GGC memory that produce
> relatively large amount of garbage (a lot of that without good reason as
> we can use malloc scheme instead, just we don't), thus I've implemented
> statistics routines. Quick checking found that for Geralds testcase
> does about 13MB of varrays, while tree-SSA does 63MB. The average
> overhead per varray is over 10KB so operands are not to blame here IMO.
and the proposed patch to make varrays allocatable either in GGC and
memory flag has been rejected and you mentioned to have better sollution
in prototype stage (moving away from varrays to sane datastructures and
improving them at the same time).
Today it seems that memory consumption on the same testcase is 122MB (up
from 63MB I reported but with realistic chance that 43MB of immediate
uses varray might go away before the freeze, but these are ggcfreed
anyway so missing in the garbage statistics) counting only the GGC
garbage, not the overall memory allocation like I did in January before
ggc_free has been implemented as can be seen in the -fmem-report:
varray.c:138 (varray_init) 59901920: 8.5% 23203392: 6.6% 11280: 0.0% 12794096: 7.5% 419188
varray.c:171 (varray_grow) 68242924: 9.7% 224774832:63.6% 271448: 0.3% 83130484:49.0% 244896
source location Garbage Freed Leak Overhead Times
Is the better sollution anywhere near to be ready (huge portion of the
arrays is still attributed to tree-ssa-dom code as can be seen in the
report attached)?
If not, I would suggest to fall back for the allocation patch at least
for 3.5 release. It has been able to cut significant portion of the
memory usage or perhaps more consistenly use ggc_free to explicitely
deallocate varrays but I don't like the overall increased overhead of
this allocation method either.
Honza
VARRAY Kind Count Bytes Resized copied
-------------------------------------------------------
bbs_to_duplicate 208 24656 15 15
reg_base_value 217 432680 717 23
Elimination Constant Copies 334 64128 0 0
immediate_uses 254956 43235680 144954 144954
vrp_variables 1775 85200 0 0
reg_equiv_memory_loc 1 440904 668 4
local_classes 1 96 0 0
processed_ptrs 1002 1358064 949 949
num_references 1002 1444588 523 92
used_temp_slots 334 68768 580 580
aliases 26707 1772144 10223 10223
ttype_data 126 20160 0 0
mangling substitutions 1 544 6 5
ehspec_data 126 12096 0 0
saved_tokens 2402 127064 107 107
ssdf_decls 1 288 0 0
referenced_vars 334 1580128 1177 1177
block_locators_locs 334 85184 147 147
reg_n_info 1 7816 14 9
build uses 334 37408 0 0
ssa_names table 334 6489088 1074 1074
work list 1336 1155840 517 517
basic blocks 334 100440 0 0
block_locators_blocks 334 159680 147 147
inlined_fns 312 137216 141 141
line_locators_locs 334 53440 0 0
prologue 1 5580 505 2
Elimination Edge List 334 37408 0 0
file_locators_locs 334 53440 0 0
ib_boundaries_block 334 1381888 489 489
Elimination Stack 334 50768 0 0
classes of registers early clobbered in an insn 334 37408 0 0
sibcall_epilogue 1 428 37 4
const_and_copies 1002 10140376 34 2
dest_array 374 41888 0 0
stack 28523 3214692 0 0
build defs 334 24048 0 0
work_stack 2076 783448 0 0
epilogue 1 6768 609 2
build v_may_defs 334 103328 357 357
build vuses 334 48368 99 99
vrp records 3213 154224 0 0
build v_must_defs 334 37408 0 0
current_lang_base 10355 1159760 0 0
first_partition 932 470516 583 577
interesting_ssa_edges 334 64608 3 3
basic blocks for the next iter. 334 100440 0 0
varying_ssa_edges 334 80768 91 91
redirection data 191 9168 0 0
cfg_blocks 334 66208 12 12
RTTI decls 1 1312 4 4
VARS worklist 1002 117504 52 52
COND worklist 1002 223984 645 645
freelist 3746 540320 8594 8594
block_data 3746 540320 8594 8594
strings 2402 691776 0 0
block_defs 28179 19576768 30032 30032
trees 932 911208 583 580
vrp_data 1002 10140376 34 2
alias sets 1 10656 1319 9
tpa nodes 269 22240 0 0
basic_block_info 668 382864 2041 785
tpa to clear 269 62408 0 0
label to block map 334 362008 1007 566
inline_parm_levels 1 48 0 0
block_nonzero_vars 6413 401232 3637 3637
block_avail_exprs 8800 1815520 719 719
part_link 269 46200 0 0
Static declarations 4 5088 1 1
line_locators_lines 334 53440 0 0
block_const_and_copies 7947 5335568 28111 28111
case_labels 21 2528 6 6
local_names 1 96 0 0
action_record_data 126 12096 0 0
file_locators_files 334 96192 0 0
stmts_to_rescan 5213 1094816 524 524
succ 12409 601680 12653 244
insn_addresses 334 638272 0 0
deferred_fns 1 65568 8 8
fns 19441 882688 0 0
pending_statics 1 8224 5 5
Elimination Node List 334 90848 0 0
-------------------------------------------------------
Total 449727 121700084
-------------------------------------------------------
next reply other threads:[~2004-09-04 9:59 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-04 9:59 Jan Hubicka [this message]
2004-09-04 18:11 ` Jeffrey A Law
2004-09-04 21:33 ` Jan Hubicka
2004-09-14 5:53 ` Jeffrey A Law
2004-09-14 10:17 ` Richard Henderson
2004-09-14 15:44 ` Jeffrey A Law
2004-09-14 12:52 ` Jan Hubicka
2004-09-14 15:41 ` Jan Hubicka
2004-09-16 16:38 ` Jeffrey A Law
2004-09-16 23:12 ` Jan Hubicka
2004-09-23 11:38 ` Jeffrey A Law
2004-10-06 20:39 ` Jan Hubicka
2004-10-06 20:52 ` Daniel Jacobowitz
2004-10-06 20:54 ` Jan Hubicka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040904095915.GV1947@kam.mff.cuni.cz \
--to=jh@suse.cz \
--cc=amacleod@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=law@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).