-----Original Message----- From: Bin.Cheng [mailto:amker.ch...@gmail.com] Sent: Friday, October 09, 2015 8:15 AM To: Ajit Kumar Agarwal Cc: GCC Patches; Vinod Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala Subject: Re: [RFC, Patch]: Optimized changes in the register used inside loop for LICM and IVOPTS.
On Thu, Oct 8, 2015 at 1:53 PM, Ajit Kumar Agarwal <ajit.kumar.agar...@xilinx.com> wrote: > > > -----Original Message----- > From: Bin.Cheng [mailto:amker.ch...@gmail.com] > Sent: Thursday, October 08, 2015 10:29 AM > To: Ajit Kumar Agarwal > Cc: GCC Patches; Vinod Kathail; Shail Aditya Gupta; Vidhumouli > Hunsigida; Nagaraju Mekala > Subject: Re: [RFC, Patch]: Optimized changes in the register used inside loop > for LICM and IVOPTS. > > On Thu, Oct 8, 2015 at 12:32 PM, Ajit Kumar Agarwal > <ajit.kumar.agar...@xilinx.com> wrote: >> Following Proposed: >> >> Changes are done in the Loop Invariant(LICM) at RTL level and also the >> Induction variable optimization based on SSA representation. >> The current logic used in LICM for register used inside the loops is >> changed. The Live Out of the loop latch node and the Live in of the >> destination of the exit nodes is used to set the Loops Liveness at the exit >> of the Loop. The register used is the number of live variables at the exit >> of the Loop calculated above. >> >> For Induction variable optimization on tree SSA representation, the >> register used logic is based on the number of phi nodes at the loop >> header to represent the liveness at the loop. Current Logic used only the >> number of phi nodes at the loop header. I have made changes to represent >> the phi operands also live at the loop. Thus number of phi operands also >> gets incremented in the number of registers used. > Hi, >>>For the GIMPLE IVO part, I don't think the change is reasonable enough. >>>IMHO, IVO fails to restrict iv number in some complex cases, your change >>>tries to >>rectify that by increasing register pressure irrespective to >>>out-of-ssa and coalescing. I think the original code models reg-pressure >>>better, what needs to be >>changed is how we compute cost from register >>>pressure and use that to restrict iv number. > > Considering the liveness with respect to all the phi arguments will > not increase the register pressure. It improves the heuristics for > restricting The IV that increases the register pressure. The cost > model uses regs_used and modelling the >>I think register pressure is increased along with regs_needed, doesn't matter >>if it will be canceled in estimate_reg_pressure_cost for both ends of cost >>>>comparison. >>Liveness with respect to the phi arguments measures > Better register pressure. >>I agree IV number should be controlled for some cases, but not by increasing >>`n' using phi argument number unconditionally. Considering summary >>>>reduction as an example, most likely the ssa names will be coalesced and >>held in single register. Furthermore, there is no reason to count phi >>node/arg >>number for floating point phi nodes. > > Number of phi nodes in the loop header is not only the criteria for > regs_used, but the number of liveness with respect to loop should be Criteria > to measure appropriate register pressure. >>IMHO, it's hard to accurately track liveness info on SSA(PHI), because of >>coalescing etc. So could you give some examples/proof for this? I agree with you that it is hard to predict the exact mapping from SSA to the actual register allocation due to coalescing and out of SSA. The Interference on phi arguments and results are important criteria for register pressure on SSA. The conventional SSA where the phi arguments don't interfere. Most of the current compilers don't have conventional SSA. In the Non-conventional SSA there are chances the phi arguments interfere. The Non-Conventional SSA arises due to the copy propagation of ssa names makes the phi arguments interfere. Due to non-conventional nature of SSA the phi arguments interfere and should be considered for the register used. I interpret the register used as the number of interfering live ranges that leads to increase or decrease in register pressure. On top of the above the Out of SSA or SSA names coalescing, for conventional SSA is quite simple as each phi nodes is assigned to new variables and the def and use is replaced with the new variables and makes the case of assigning single register and then the corresponding phi node is removed. But in the Non- Conventional nature of SSA, the out of ssa makes the SSA conventional by inserting copying to each of the predecessor node and assigned it to new variable on each of the predecessor nodes and the phi node is replaced with new variables of the copy results generated in each of the predecessor as phi arguments and assigned to a new result and the copy is inserted after the phi nodes with source as the new phi result to a new variable. This makes the SSA conventional and out of ssa uses the above approach for conventional to remove the phi nodes and replace the def and use. This nature of out of SSA for non- conventional SSA increases the copy instructions and thus lead to increase in register pressure. Though aggressive and conservative coalescing remove some of the copy instruction but not possible to remove all the copy instructions. I liked the approach of calculating the number of phi nodes in the loop header because of the following properties of SSA. The SSA variables that are live at the live at the header should be live at all other nodes of the Loop because of the SSA properties of header dominates the all other nodes of the Loop. The current implementation of the number of phi nodes to the register used in GIMPLE IVOPTS is not appropriate and sufficient reasons to consider the register used. The number of phi arguments should also be considered to have an effect of register pressure on the number of IVS. This concludes to consider the number of interfering phi arguments of non-conventional SSA in the register used effecting the register pressure. If you have any examples that impacted the above, Please share with us. Thanks & Regards Ajit Thanks, bin > > Thanks & Regards > Ajit
