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.
