On 8/31/20 9:33 PM, Jiufu Guo via Gcc-patches wrote:
> guojiufu <guoji...@linux.ibm.com> writes:
>
> Hi,
>
> In this patch, the default value of
> param=max-unrolled-average-calls-x10000 is '0', which means to unroll
> a loop, there should be no call inside the body. Do I need to set the
> default value to a bigger value (16?) for later tune? Biger value will
> keep the behavior unchanged.
>
> And is this patch ok for trunk? Thanks a lot for you comments!
>
> BR.
> Jiufu.
>
>
>> Hi,
>>
>> 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.
jeff
