This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH GCC8][29/33]New register pressure estimation
- From: "Bin.Cheng" <amker dot cheng at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 7 Jun 2017 12:02:34 +0100
- Subject: Re: [PATCH GCC8][29/33]New register pressure estimation
- Authentication-results: sourceware.org; auth=none
- References: <VI1PR0802MB21762496F9B6DE1526FFE97EE7190@VI1PR0802MB2176.eurprd08.prod.outlook.com> <CAFiYyc0RHp6Z8dm+N4ruXqS5BtXDK_Z8TXFoYyqA7E1pUPzNKw@mail.gmail.com> <CAHFci29mP20=WEXSWwRK=3aRBbFYvHrK5rFcO=kUfkJ8ddxqFQ@mail.gmail.com> <CAFiYyc3X3M=Sg_jGCoTZFvueZVayvYbr44oBFq3g4Y9-vYD3Tw@mail.gmail.com>
On Wed, May 17, 2017 at 1:24 PM, Richard Biener
> On Mon, May 15, 2017 at 5:50 PM, Bin.Cheng <email@example.com> wrote:
>> On Thu, May 11, 2017 at 11:39 AM, Richard Biener
>> <firstname.lastname@example.org> wrote:
>>> On Tue, Apr 18, 2017 at 12:53 PM, Bin Cheng <Bin.Cheng@arm.com> wrote:
>>>> 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.
>> I removed the hot innermost part and here is the updated version. Is it OK?
Sorry for the long time delay, I committed the patch @r248954
>> 2017-05-11 Bin Cheng <email@example.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
>>>> 2017-04-11 Bin Cheng <firstname.lastname@example.org>
>>>> * 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
>>>> (determine_hot_innermost_loop): New.
>>>> (tree_ssa_iv_optimize_loop): Call above function.