[Patch,optimization]: Optimized changes in the estimate register pressure cost.

Ajit Kumar Agarwal ajit.kumar.agarwal@xilinx.com
Tue Sep 29 08:03:00 GMT 2015



-----Original Message-----
From: Aaron Sawdey [mailto:acsawdey@linux.vnet.ibm.com] 
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  <ajitkum@xilinx.com>
> 
> 	* 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 ajitkum@xilinx.com

>>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.  acsawdey@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782 IBM Linux Technology Center - PPC Toolchain



More information about the Gcc-patches mailing list