https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #55 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Richard Biener from comment #50) > (In reply to Richard Biener from comment #4) > > Trunk at -O1: > > > > dominator optimization : 495.14 ( 82%) 0.20 ( 5%) 495.44 ( > > 81%) 113M ( 5%) > > Compared to that we're now at the following state with -O1 (everything >= > 4%): > > callgraph ipa passes : 17.23 ( 10%) > df live regs : 6.76 ( 4%) > dominator optimization : 89.76 ( 50%) > backwards jump threading : 7.94 ( 4%) > TOTAL : 180.77 > > So it's still DOM aka forward threading eating most of the time. > -fno-thread-jumps improves compile-time to 77s, DOM then still takes 25s > (33%) > (top offenders are then dom_oracle::register_transitives, bitmap_set_bit > and wide_int_storage copying). I noticed the unbound dominator traversal > in register_transitives already. Theres already a creation flag to disable registering transitives if we decide we don't want them due to their expense. fast VRP disables them always, but regular VRP never disables it. We switch to fast vrp when the size of the CFG goes beyond a threshold. The threader will use a normal ranger, so it isn't getting the benefit of this flag. It would be simple enough to disable transitives in ranger if the CFG is beyond a specified size, and we could use the same --param VRP uses to switch algorithms. something like this ought to remove that hotspot: diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc index 4b94e0db7aa..f665925f630 100644 --- a/gcc/gimple-range-cache.cc +++ b/gcc/gimple-range-cache.cc @@ -1003,7 +1003,8 @@ ranger_cache::ranger_cache (int not_executable_flag, bool use_imm_uses) m_temporal = new temporal_cache; // If DOM info is available, spawn an oracle as well. - create_relation_oracle (); + bool transitives_p = (last_basic_block_for_fn (cfun) < param_vrp_block_limit); + create_relation_oracle (transitives_p); create_infer_oracle (use_imm_uses); create_gori (not_executable_flag, param_vrp_switch_limit);