[Bug tree-optimization/26854] Inordinate compile times on large routines

[rguenth at gcc dot gnu.org]

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

--- Comment #134 from Richard Biener <rguenth at gcc dot gnu.org> ---
We can see from _num.i detailled stats

df_chain_block pool             df-problems.c:2398 (df_chain_alloc)            
    152         0:  0.0% 937593072  61860737: 90.1%          24

which shows an odd element size (expected is 16) which comes from
base_pool_allocator::allocation_object having a ALLOC_POOL_ID_TYPE member
by default.

Then we have (bitmaps)

df-problems.c:1914 (df_mir_alloc)                    615680:  0.2% 249285640 
12495192: 13.3%           0           0      heap
df-problems.c:1915 (df_mir_alloc)                    615880:  0.2% 249285680 
12495197: 13.3%           0           0      heap
...
tree-ssa-structalias.c:1268 (build_pred_graph)     62026224: 15.9%  62048368  
7961338:  8.5%      186859      248364      heap
df-problems.c:3658 (df_note_compute)               88025520: 22.6%  88026080  
3719686:  4.0%      515641     1741186      heap
df-problems.c:4405 (df_md_alloc)                  -39759960:4741239668736.0%   
   -40    520627:  0.6%           0           0      heap
df-problems.c:225 (df_rd_alloc)                   -17948440:4741239668736.0%   
   -40    284572:  0.3%           0           0      heap

with the overflow thing (and the odd leaks which probably are not properly
tracking when we release bitmaps via releasing the bitmap obstack?)

Most interesting is the peak number, highest for df_mir_alloc.  Eventually
we can do sth to shrink that peak usage by freeing unneeded bitmaps
earlier.

Compile-time looks reasonable.

I'll have a look at the accounting overflows and reducing the pool allocator
overhead as well as looking at the MIR problem bitmap use.