On Thu, Nov 19, 2020 at 12:13:34PM -0700, Jeff Law wrote: > On 8/31/20 9:33 PM, Jiufu Guo via Gcc-patches wrote: > > guojiufu <guoji...@linux.ibm.com> writes: > >> When unroll loops, if there are calls inside the loop, those calls > >> may raise negative impacts for unrolling. This patch adds a param > >> param_max_unrolled_calls, and checks if the number of calls inside > >> the loop bigger than this param, loop is prevent from unrolling. > >> > >> This patch is checking the _average_ number of calls which is the > >> summary of call numbers multiply the possibility of the call maybe > >> executed. The _average_ number could be a fraction, to keep the > >> precision, the param is the threshold number multiply 10000. > >> > >> Bootstrap and regtest pass on powerpc64le. Is this ok for trunk? > >> > >> gcc/ChangeLog > >> 2020-08-19 Jiufu Guo <guoji...@cn.ibm.com> > >> > >> * params.opt (param_max_unrolled_average_calls_x10000): New param. > >> * cfgloop.h (average_num_loop_calls): New declare. > >> * cfgloopanal.c (average_num_loop_calls): New function. > >> * loop-unroll.c (decide_unroll_constant_iteration, > >> decide_unroll_runtime_iterations, > >> decide_unroll_stupid): Check average_num_loop_calls and > >> param_max_unrolled_average_calls_x10000. > So what's the motivation behind adding a PARAM to control this > behavior? I'm not a big fan of exposing a lot of PARAMs for users to > tune behavior (though I've made the same lapse in judgment myself). In > my mind a PARAM is really more about controlling pathological behavior.
But we (Power) need very different tuning than what others apparently need. It is similar to inlining, in that that also differs a lot between archs how aggressively to do that optimally. Segher
