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

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

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.