[PATCH v2 2/3] Add predict_doloop_p target hook

[Kewen.Lin]

on 2019/5/15 上午11:34, Kewen.Lin wrote:
> 
> on 2019/5/15 上午10:40, Bin.Cheng wrote:
>> I wonder if you can factor out generic part into GIMPLE and leave
>> target hook as specific as possible?
>>
> 
> Good suggestion! Yes, most of the checks are common as you
> pointed out.  I hope the other targets won't have more
> customization needs excepting for that GIMPLE stmt hook
> check. 
> 
> I am thinking IVOPTs is a best place to factor to? Or 
> somewhere to put common GIMPLE query interface? 
> 

Or move it into targhooks.cpp as a possible base process 
of [target]_predict_doloop_p?   The target owner can
decide whether to use generic_predict_doloop_p in its 
own target hook.
It seems more flexible and allow them to have a new 
implementation for their own targets.  Like:

rs6000_predict_doloop_p:
	....
	if (generic_predict_doloop_p(loop))
	...

special_target_predict_doloop_p:
	....
	....


Thanks,
Kewen

>>> +
>>> +  /* Similar to doloop_optimize, check whether iteration count too small
>>> +     and not profitable.  */
>>> +  HOST_WIDE_INT est_niter = get_estimated_loop_iterations_int (loop);
>>> +  if (est_niter == -1)
>>> +    est_niter = get_likely_max_loop_iterations_int (loop);
>>> +  if (est_niter >= 0 && est_niter < 3)
>> The only probably target dependent is the magic number 3 here.  After
>> moving all generic part to ivopts, we can use a macro for the moment,
>> and improve it as a parameter if there are more doloop targets.
> 
> The magic number 3 is from function doloop_optimize, not a
> target dependent value.  But thanks for your tips with 
> macro mechanism!
> 
> 
> Thanks,
> Kewen
> 
>> Overall most of above checks can be moved out of backend, leaving only
>> more specific target hook checking on gimple_stmt?  And even that can
>> be made generic to some extend.
>>
>> Thanks,
>> bin
>