On Tue, Sep 29, 2015 at 2:25 AM, Aaron Sawdey <[email protected]> wrote: > 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?
With this, I think the only change would be in GIMPLE IVOPT? The patch increases register pressure if it exceeds available register number when choosing iv candidates. As I mentioned, it may only have impact on scenarios that's on the verge of available register number, otherwise the reg_old is added(thus cancelled) for both ends of comparison. The result isn't clear enough even for boundary cases because IVO now has issues in computing the "starting register pressure". I also planned to visit the pressure model in IVO later. Thanks, bin > >> >> 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 >
