-----Original Message-----
From: Aaron Sawdey [mailto:[email protected]] 
Sent: Monday, September 28, 2015 11:55 PM
To: Ajit Kumar Agarwal
Cc: GCC Patches; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; 
Nagaraju Mekala
Subject: Re: [Patch,optimization]: Optimized changes in the estimate register 
pressure cost.

On Sat, 2015-09-26 at 04:51 +0000, Ajit Kumar Agarwal wrote:
> I have made the following changes in the estimate_reg_pressure_cost 
> function used by the loop invariant and IVOPTS.
> 
> Earlier the estimate_reg_pressure cost uses the cost of n_new 
> variables that are generated by the Loop Invariant  and IVOPTS. These 
> are not sufficient for register pressure calculation. The register 
> pressure cost calculation should use the n_new + n_old (numbers) to 
> consider the cost. n_old is the register  used inside the loops and 
> the effect of  n_new new variables generated by loop invariant and 
> IVOPTS on register pressure is based on how the new variables impact 
> on register used inside the loops. The increase or decrease in register 
> pressure is due to the impact of new variables on the register used  inside 
> the loops. The register-register move cost or the spill cost should consider 
> the cost associated with register used and the new variables generated. The 
> movement  of new variables increases or decreases the register pressure, 
> which is based on  overall cost of n_new + n_old variables.
> 
> The increase and decrease in register pressure is based on the overall 
> cost of n_new + n_old as the changes in the register pressure caused 
> due to new variables is based on how the changes behave with respect to the 
> register used in the loops.
> 
> Thus the register pressure caused to new variables is based on the new 
> variables and its impact on register used inside  the loops and thus consider 
> the overall  cost of n_new + n_old.
> 
> Bootstrap for i386 and reg tested on i386 with the change is fine.
> 
> SPEC CPU 2000 benchmarks are run and there is following impact on the 
> performance and code size.
> 
> ratio with the optimization vs ratio without optimization for INT 
> benchmarks
> (3807.632 vs 3804.661)
> 
> ratio with the optimization vs ratio without optimization for FP 
> benchmarks ( 4668.743 vs 4778.741)
> 
> Code size reduction with respect to FP SPEC CPU 2000 benchmarks
> 
> Number of instruction with optimization = 1094117 Number of 
> instruction without optimization = 1094659
> 
> Reduction in number of instruction with the optimization = 542 instruction.
> 
> [Patch,optimization]: Optimized changes in the estimate  register 
> pressure cost.
> 
> Earlier the estimate_reg_pressure cost uses the cost of n_new 
> variables that are generated by the Loop Invariant and IVOPTS. These 
> are not sufficient for register pressure calculation. The register 
> pressure cost calculation should use the n_new + n_old (numbers) to 
> consider the cost. n_old is the register used inside the loops and the 
> affect of n_new new variables generated by loop invariant and IVOPTS 
> on register pressure is based on how the new variables impact on register 
> used inside the loops.
> 
> ChangeLog:
> 2015-09-26  Ajit Agarwal  <[email protected]>
> 
>       * cfgloopanal.c (estimate_reg_pressure_cost) : Add changes
>       to consider the n_new plus n_old in the register pressure
>       cost.
> 
> Signed-off-by:Ajit Agarwal [email protected]

>>Ajit,

 >>It looks to me like your change doesn't do anything at all inside the 
 >>loop-invariant.c code. There it's doing a difference between two 
 >>>>estimate_reg_pressure_cost calls so adding n_old (regs_used) to both is 
 >>canceled out.

>>      size_cost = (estimate_reg_pressure_cost (new_regs[0] + regs_needed[0],
>>                                              regs_used, speed, call_p)
>>                   - estimate_reg_pressure_cost (new_regs[0],
>>                                                 regs_used, speed, call_p));

>>I'm not quite sure I understand the "why" of the heuristic you've added here 
>>-- can you explain your reasoning further?

Aaron:

Extract from function estimate_reg_pressure_cost() where the changes are made.

if (regs_needed <= available_regs)
    /* If we are close to running out of registers, try to preserve
       them.  */
/* Case 1 */
cost = target_reg_cost [speed] * regs_needed ;
  else
    /* If we run out of registers, it is very expensive to add another
       one.  */
 /* Case 2*/
    cost = target_spill_cost [speed] * regs_needed;

If the first estimate_reg_pressure falls into the category of Case I or Case 2 
and the second estimate_reg_pressure falls into same Category for Case1 Or 
Case2 then it will be cancelled out. If both the estimate_reg_pressure falls 
into different category like first One falls into Case 2 and second one falls 
into Case 1, then it will not be cancelled out as the target_reg_cost[speed] 
and target_spill_cost[speed] are different.

The changes works out simply for tree-ssa-ivopts(TREE IVOPTS).

I have earlier sent the patch for the loop-invariant changes in the cases where 
it gets cancelled. The change is mentioned below for reference. The reference 
msg is 
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00196.html
 While sending that patch I had done measurements wth MiBench/EEMBC benchmarks 
for MicroBlaze Target.

size_cost = (estimate_reg_pressure_cost ( regs_needed[0],
                                           regs_used, speed, call_p);

Thanks & Regards
Ajit

> 
> Thanks & Regards
> Ajit
> 

Thanks,
    Aaron

--
Aaron Sawdey, Ph.D.  [email protected]
050-2/C113  (507) 253-7520 home: 507/263-0782 IBM Linux Technology Center - PPC 
Toolchain

Reply via email to