[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114480

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #14)
> Created attachment 57829 [details]
> smaller testcase
> 
> Smaller testcase, shows the same compile-time issue at -O0.  At -O1 it's a
> lot
> less bad but memory usage is better (8GB), so the slowness of the full
> testcase
> is likely memory bandwidth related.
> 
> -O1 is then
> 
>  tree PTA                           :  20.59 ( 21%)
>  expand vars                        :   9.19 (  9%)
>  expand                             :  14.26 ( 15%)

The memory use goes into RTXen created during RTL expansion.  The compile-time
part is add_scope_conflicts.  There's the possibility to do like
var-tracking and use rev_post_order_and_mark_dfs_back_seme, avoiding iteration
for non-loops and have better cache locality.

We have half of the profile hits on ggc_internal_alloc and it's

    17 | d8:+- mov    %r14,%rax                                                
                     #
       |    |  mov    (%r14),%r14                                              
                     #
  1440 |    |  test   %r14,%r14                                                
                     #
     4 |    |  je     530                                                      
                     #
       |    |if (p->bytes == entry_size)                                       
                     #
       | e7:|  cmp    0x10(%r14),%r12                                          
                     #
 65582 |    +--jne    d8                   

which is the linear walk

  /* Check the list of free pages for one we can use.  */
  for (pp = &G.free_pages, p = *pp; p; pp = &p->next, p = *pp) 
    if (p->bytes == entry_size)
      break;

so we seem to have many free pages for some reason but the free pages
pool is global and not per order?!

Samples: 299K of event 'cycles', Event count (approx.): 338413178083            
Overhead       Samples  Command  Shared Object       Symbol                     
  23.16%         67756  cc1plus  cc1plus             [.] ggc_internal_alloc
   6.98%         21637  cc1plus  cc1plus             [.] bitmap_tree_splay
   6.89%         20413  cc1plus  cc1plus             [.] bitmap_ior_into
   4.05%         11989  cc1plus  cc1plus             [.] bitmap_elt_ior
   3.16%          9840  cc1plus  cc1plus             [.] mergesort<sort_ctx>
   2.90%          8860  cc1plus  cc1plus             [.] bitmap_set_bit
   2.76%          8281  cc1plus  cc1plus             [.]
get_ref_base_and_extent
   1.37%          4071  cc1plus  cc1plus             [.]
stmt_may_clobber_ref_p_1
   1.32%          4095  cc1plus  cc1plus             [.] dominated_by_p
   1.16%          3597  cc1plus  cc1plus             [.]
bitmap_tree_unlink_element
   1.06%          3128  cc1plus  cc1plus             [.] walk_aliased_vdefs_1

the bitmap_tree_splay is from compute_idf, refactoring that some more,
also avoiding the duplicate processing and doing away with the bitmap
for the workset might help a bit there (not using tree view just gets
set-bit up with no overall positive change).

I will look into the above things more (but not the RA slowness at -O0).