http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #91 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-05-03
17:34:56 UTC ---
Hi,
with the patch I just posted for removal of hash tables for cgraph/varpool node
set, the situation with hashing is better. We got from 900s WPA stage to 500s
WPA stage.
Streaming still dominate:
ipa lto decl in : 331.26 (56%) usr 5.51 (34%) sys 337.11 (56%) wall
722314 kB (46%) ggc
ipa lto decl out : 118.21 (20%) usr 4.37 (27%) sys 122.57 (20%) wall
0 kB ( 0%) ggc
ipa lto decl merge : 23.61 ( 4%) usr 0.20 ( 1%) sys 23.83 ( 4%) wall
962 kB ( 0%) ggc
inline heuristics : 57.12 (10%) usr 0.14 ( 1%) sys 57.27 ( 9%) wall
227500 kB (14%) ggc
TOTAL : 587.02 16.36 604.01
1585790 kB
(I have plans for fixing inliner once more prominent problems are solved)
Streaming in oprofile:
150985 20.6876 lto1 htab_find_slot_with_hash
71532 9.8012 lto1 gimple_types_compatible_p
55971 7.6690 libc-2.11.1.so _int_malloc
55104 7.5502 lto1 iterative_hash_hashval_t
33160 4.5435 lto1 type_pair_eq
31554 4.3235 libc-2.11.1.so memset
25670 3.5172 lto1 gtc_visit
23972 3.2846 lto1 gimple_type_hash_1
21562 2.9544 lto1 lto_input_tree
15230 2.0868 lto1 gt_ggc_mx_lang_tree_node
14807 2.0288 lto1 inflate_fast
callgrind profile (of javascript instead of libxul) shows that tree_map_base
hash is the most busy one:
453,603,428 *
libiberty/../../libiberty/hashtab.c:htab_find_slot_with_hash'2
33,167,620 > gcc/../../gcc/tree.c:tree_map_base_eq (6633524x)
134,245,948 > libiberty/../../libiberty/hashtab.c:htab_expand (18x)
25,459,797 > gcc/../../gcc/gimple.c:type_pair_eq (2793149x)
and the users of hashing:
63,519,720 < /libiberty/hashtab.c:htab_find_slot'2 (676308x)
3,975,492,482 < /libiberty/hashtab.c:htab_find_slot (2179693x)
255,072,048 * /libiberty/hashtab.c:htab_find_slot_with_hash
14,530,222 < /gcc/gimple.c:iterative_hash_gimple_type'2 (52634x)
526,622,873 < /gcc/gimple.c:lookup_type_pair.isra.103.constprop.111
(1621144x)
17,415,611 < /gcc/gimple.c:iterative_hash_gimple_type (100893x)
11,734,620 < /gcc/gimple.c:visit'2 (98730x)
432,531,796 < /gcc/gimple.c:gimple_type_hash_1 (3851023x)
35,405,473 < /gcc/gimple.c:visit (319520x)
108,790,992 * /libiberty/hashtab.c:htab_find_slot'2
Oprofile of the whole build shows also problem in decl_assembler_name_equal
(because of our stupit alias hacks) and can_inline_edge_p. I will look into
those two.
260739 7.1750 lto1 lto1
htab_find_slot_with_hash
151080 4.1574 lto1 lto1
decl_assembler_name_equal
130969 3.6040 libc-2.11.1.so libc-2.11.1.so _int_malloc
100723 2.7717 lto1 lto1
gimple_types_compatible_p
97370 2.6794 lto1 lto1
iterative_hash_hashval_t
75051 2.0653 libc-2.11.1.so libc-2.11.1.so memset
56508 1.5550 lto1 lto1
bitmap_set_bit
53211 1.4643 lto1 lto1
can_inline_edge_p
51613 1.4203 oprofiled oprofiled
/usr/bin/oprofiled
49992 1.3757 lto1 lto1
pointer_map_insert
48381 1.3313 lto1 lto1
lto_input_tree
44467 1.2236 lto1 lto1
type_pair_eq
35096 0.9658 libc-2.11.1.so libc-2.11.1.so _int_free
35069 0.9650 lto1 lto1 gtc_visit
(this is including ltrans stage)
Honza
