https://bugzilla.suse.com/show_bug.cgi?id=1202027 https://bugzilla.suse.com/show_bug.cgi?id=1202027#c17 --- Comment #17 from Richard Biener <rguenther@suse.com> --- (In reply to Martin Li��ka from comment #16)
(In reply to Richard Biener from comment #15)
(In reply to Martin Li��ka from comment #14)
These functions are affected:
;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_empty_slot_for_expand (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE26find_e mpty_slot_for_expandEj, funcdef_no=3135, decl_uid=118436, cgraph_uid=2254, symbol_order=2435)
That's a tree hash (I think using pointer hashing).
;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_slot_with_hash (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE19find_s lot_with_hashERKS2_j13insert_option, funcdef_no=2928, decl_uid=118365, cgraph_uid=2047, symbol_order=2228) ;; Function hash_table_mod2 (_Z15hash_table_mod2jj, funcdef_no=1065, decl_uid=33219, cgraph_uid=354, symbol_order=368)
But this suggests the actual table load differs?!
;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_empty_slot_for_expand (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_h ash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE26find_empty_slot_for_expa ndEj, funcdef_no=3327, decl_uid=112248, cgraph_uid=2446, symbol_order=2623) ;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_slot_with_hash (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_h ash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE19find_slot_with_hashERKS2 _j13insert_option, funcdef_no=3056, decl_uid=112177, cgraph_uid=2175, symbol_order=2352) ;; Function hash_table<hash_map<tree_node*, tree_node*>::hash_entry, false, xcallocator>::find_with_hash (_ZN10hash_tableIN8hash_mapIP9tree_nodeS2_21simple_hashmap_traitsI19default_h ash_traitsIS2_ES2_EE10hash_entryELb0E11xcallocatorE14find_with_hashERKS2_j, funcdef_no=3048, decl_uid=112166, cgraph_uid=2167, symbol_order=2344) ;; Function hash_table<default_hash_traits<tree_node*>, false, xcallocator>::find_with_hash (_ZN10hash_tableI19default_hash_traitsIP9tree_nodeELb0E11xcallocatorE14find_w ith_hashERKS2_j, funcdef_no=2698, decl_uid=118471, cgraph_uid=1818, symbol_order=2019) ;; Function get_terminal_width (_Z18get_terminal_widthv, funcdef_no=1638, decl_uid=40874, cgraph_uid=752, symbol_order=778) ;; Function hash_table<indirect_string_hasher>::find_slot_with_hash (_ZN10hash_tableI22indirect_string_hasherLb0E11xcallocatorE19find_slot_with_h ashERKPKcj13insert_option, funcdef_no=3536, decl_uid=133145, cgraph_uid=2647, symbol_order=2952) ;; Function ggc_internal_cleared_alloc (_Z26ggc_internal_cleared_allocmPFvPvEmm, funcdef_no=1531, decl_uid=30171, cgraph_uid=670, symbol_order=708) ;; Function ggc_internal_alloc (_Z18ggc_internal_allocmPFvPvEmm, funcdef_no=2551, decl_uid=30102, cgraph_uid=1662, symbol_order=1833)
And these suggest the same - do we see the invocation count of ggc_internal_alloc and does that differ?
Yes, it is:
;; Function ggc_internal_alloc (_Z18ggc_internal_allocmPFvPvEmm, funcdef_no=2551, decl_uid=30102, cgraph_uid=1662, symbol_order=1833) ... -Read edge from 0 to 2, count:1113521085 +Read edge from 0 to 2, count:1113521086
Huh. Difference by one :/
Read edge from 3 to 5, count:60717 Read edge from 4 to 5, count:14486906 -Read edge from 4 to 14, count:1098973462 +Read edge from 4 to 14, count:1098973463
The first edge is entry count. [...]
in the end most of the above could be secondary order effects by getting different profile for different generated code? We profile the stage2 compiler after all?
Is a different generated code expected? Yes, we profile stage2 compiler.
No, it's the bug that we generate different code ... but of course this would affect non-FDO, -fprofile-generate code then instead of -fprofile-use. -- You are receiving this mail because: You are on the CC list for the bug.