https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854
--- Comment #130 from Paolo Bonzini <bonzini at gnu dot org> --- A late update... all.i: with GCC 4.8.3 on a Xeon E5 v3 time is taken mostly by alias stmt walking alias stmt walking : 272.52 (65%) (-O2) alias stmt walking : 116.06 (67%) (-O1) Requred memory is 700 MB. With GCC 5.1, but on a Core i7 Ivy Bridge laptop so times are not comparable, time is also taken mostly by alias stmt walking: alias stmt walking : 604.43 (54%) usr (-O1) and memory usage is also around 700 MB. Brad was using -fschedule-insns too, and it's pretty expensive: scheduling : 430.61 (38%) (-O1 -fschedule-insns, 5.1) scheduling : 122.68 (41%) (-O1 -fschedule-insns, 4.8.3) It also brings the top memory usage to 1 GB. --------------------- compile.i: with GCC 4.8.3 time is taken mostly by scheduling and some tree passes (-O1): alias stmt walking : 206.77 (36%) tree CFG cleanup : 42.66 ( 7%) usr 0.02 ( 0%) sys 42.65 ( 7%) wall 1108 kB ( 0%) ggc dominator optimization : 39.98 ( 7%) usr 0.04 ( 1%) sys 39.97 ( 7%) wall 23123 kB ( 3%) ggc Required memory is around 1 GB. I haven't tested 5.1 but the alias stmt walking seems to be a common feature of the Gambit testcases. In both cases, memory usage is at least under control. However, total compile time has regressed since the previous report in comment 115. As expected walk_aliased_vdefs has a high % of time spent, but the time is spent in bitmap operations rather than the callbacks! This is because the callback is the trivial mark_modified function. The guilty walk_aliased_vdefs invocation is parm_ref_data_preserved_p, invoked from ipa_load_from_parm_agg and in turn from unmodified_parm_or_parm_agg_item. Memoization via parms_ainfo seems like a plan, I'm opening a separate bug.
