This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH GCC8][29/33]New register pressure estimation


On Wed, May 17, 2017 at 1:24 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Mon, May 15, 2017 at 5:50 PM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>> On Thu, May 11, 2017 at 11:39 AM, Richard Biener
>> <richard.guenther@gmail.com> wrote:
>>> On Tue, Apr 18, 2017 at 12:53 PM, Bin Cheng <Bin.Cheng@arm.com> wrote:
>>>> Hi,
>>>> Currently IVOPTs shares the same register pressure computation with RTL loop invariant pass,
>>>> which doesn't work very well.  This patch introduces specific interface for IVOPTs.
>>>> The general idea is described in the cover message as below:
>>>>   C) Current implementation shares the same register pressure computation with RTL loop
>>>>      inv pass.  It has difficulty in handling (especially large) loop nest, and quite
>>>>      often generating too many candidates (especially for outer loops).  This change
>>>>      introduces new register pressure computation.  The brief idea is to differentiate
>>>>      (hot) innermost loop and outer loop.  for (possibly hot) inner most, more registers
>>>>      are allowed as long as the register pressure is within the range of number of target
>>>>      available registers.
>>>> It can also help to restrict number of candidates for outer loop.
>>>> Is it OK?
>>>
>>> +/* Determine if current loop is the innermost loop and maybe hot.  */
>>> +
>>> +static void
>>> +determine_hot_innermost_loop (struct ivopts_data *data)
>>> +{
>>> +  data->hot_innermost_loop_p = true;
>>> +  if (!data->speed)
>>> +    return;
>>>
>>> err, so when not optimizing for speed we assume all loops (even not innermost)
>>> are hot and innermost?!
>>>
>>> +  HOST_WIDE_INT niter = avg_loop_niter (loop);
>>> +  if (niter < PARAM_VALUE (PARAM_AVG_LOOP_NITER)
>>> +      || loop_constraint_set_p (loop, LOOP_C_PROLOG)
>>> +      || loop_constraint_set_p (loop, LOOP_C_EPILOG)
>>> +      || loop_constraint_set_p (loop, LOOP_C_VERSION))
>>> +    data->hot_innermost_loop_p = false;
>>>
>>> this needs adjustment for the constraint patch removal.  Also looking at niter
>>> of the loop in question insn't a good metric for hotness.  data->speed is the
>>> best guess you get I think (optimize_loop_for_speed_p).
>>>
>>>    data->speed = optimize_loop_for_speed_p (loop);
>>> +  determine_hot_innermost_loop (data);
>>>
>>>   data->hot_innermost_loop_p = determine_hot_innermost_loop (data);
>>>
>>> would be more consistent here.
>> Hi,
>> I removed the hot innermost part and here is the updated version.  Is it OK?
>
> Ok.
Sorry for the long time delay, I committed the patch @r248954

Thanks,
bin
>
>> Thanks,
>> bin
>>
>> 2017-05-11  Bin Cheng  <bin.cheng@arm.com>
>>
>>     * tree-ssa-loop-ivopts.c (ivopts_estimate_reg_pressure): New
>>     reg_pressure model function.
>>     (ivopts_global_cost_for_size): Delete.
>>     (determine_set_costs, iv_ca_recount_cost): Call new model function
>>     ivopts_estimate_reg_pressure.
>>
>>>
>>> Thanks,
>>> Richard.
>>>
>>>> Thanks,
>>>> bin
>>>> 2017-04-11  Bin Cheng  <bin.cheng@arm.com>
>>>>
>>>>         * tree-ssa-loop-ivopts.c (struct ivopts_data): New field.
>>>>         (ivopts_estimate_reg_pressure): New reg_pressure model function.
>>>>         (ivopts_global_cost_for_size): Delete.
>>>>         (determine_set_costs, iv_ca_recount_cost): Call new model function
>>>>         ivopts_estimate_reg_pressure.
>>>>         (determine_hot_innermost_loop): New.
>>>>         (tree_ssa_iv_optimize_loop): Call above function.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]