Comment # 17 on bug 1202027 from Richard Biener

(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.