[PATCH] Check calls before loop unrolling

[Jeff Law]

On 8/31/20 9:33 PM, Jiufu Guo via Gcc-patches wrote:
> guojiufu <guojiufu@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   <guojiufu@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