Qing Zhao <qing.z...@oracle.com> writes: > (gdb) where > #0 0x0000000000ddbcb3 in df_chain_create (src=0x631006480f08, > dst=0x63100f306288) at ../../gcc-8.2.1-20180905/gcc/df-problems.c:2267 > #1 0x0000000000dddd1a in df_chain_create_bb_process_use ( > local_rd=0x7ffc109bfaf0, use=0x63100f306288, top_flag=0) > at ../../gcc-8.2.1-20180905/gcc/df-problems.c:2441 > #2 0x0000000000dde5a7 in df_chain_create_bb (bb_index=16413) > at ../../gcc-8.2.1-20180905/gcc/df-problems.c:2490 > #3 0x0000000000ddeaa9 in df_chain_finalize (all_blocks=0x63100097ac28) > at ../../gcc-8.2.1-20180905/gcc/df-problems.c:2519 > #4 0x0000000000dbe95e in df_analyze_problem (dflow=0x60600027f740, > blocks_to_consider=0x63100097ac28, postorder=0x7f23761f1800, > n_blocks=40768) at ../../gcc-8.2.1-20180905/gcc/df-core.c:1179 > #5 0x0000000000dbedac in df_analyze_1 ()
AFAIK df_analyze is used even with O1 by various passes. Probably tbe bulk of the memory consumption is somewhere else, and it just happens to hit there by chance. Would be useful to figure out in more details where the memory consumption goes in your test case. Unfortunately gcc doesn't have a good general heap profiler, but I usually do (if you're on Linux). Whoever causes most page faults likely allocates most memory. perf record --call-graph dwarf -e page-faults gcc ... perf report --no-children --percent-limit 5 --stdio > file.txt and post file.txt into a bug in bugzilla. -Andi
