On Mon, Jul 6, 2015 at 1:16 PM, Ajit Kumar Agarwal <ajit.kumar.agar...@xilinx.com> wrote: > > > -----Original Message----- > From: Bin.Cheng [mailto:amker.ch...@gmail.com] > Sent: Monday, July 06, 2015 10:26 AM > To: Ajit Kumar Agarwal > Cc: Steven Bosscher; l...@redhat.com; Richard Biener; gcc@gcc.gnu.org; Vinod > Kathail; Shail Aditya Gupta; Vidhumouli Hunsigida; Nagaraju Mekala > Subject: Re: Live on Exit renaming. > > On Mon, Jul 6, 2015 at 12:02 PM, Ajit Kumar Agarwal > <ajit.kumar.agar...@xilinx.com> wrote: >> >> >> -----Original Message----- >> From: Bin.Cheng [mailto:amker.ch...@gmail.com] >> Sent: Monday, July 06, 2015 7:04 AM >> To: Steven Bosscher >> Cc: Ajit Kumar Agarwal; l...@redhat.com; Richard Biener; >> gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta; Vidhumouli >> Hunsigida; Nagaraju Mekala >> Subject: Re: Live on Exit renaming. >> >> On Mon, Jul 6, 2015 at 6:02 AM, Steven Bosscher <stevenb....@gmail.com> >> wrote: >>> On Sat, Jul 4, 2015 at 3:45 PM, Ajit Kumar Agarwal wrote: >>>> I am not sure why the above optimization is not implemented in GCC. >>> >>> -fsplit-ivs-in-unroller >> >>>>And thing might have changed. Given the condition GCC does IVO on gimple, >>>>unrolling on RTL, there is inconsistency between the two optimizer since >>>>IVO >>takes register pressure of IVs into consideration and assumes IVs >>>>will take single registers. At least for some cases, splitting live range >>>>of IVs results in bad >>code. See PR29256 for more information. As >>>>described in the comment, actually I am going to do some experiments >>>>disabling such transformation to see >>what happens. >> >> The above optimization is implemented as a part of unroller in gimple. >> There is an unroller pass in rtl which does not have support for this >>>As far as I understand, fsplit-ivs-in-unroller is a transformation in RTL >>>unroller. > > My mistake. Yes you are right. The fsplit-ivs-in-unroller is a transformation > in RTL unroller. > IVO on gimple doesn't take unrolling into consideration and assume to assign > single register for IV candidates. My thinking is that > Splitting IVs at RTL with the unroller removes the long dependent chains and > thus makes the overlapping iterations and better > Register allocators and there is a chance of movement of independent code > that got exposes with split-ivs-in-unroller. > > You have mentioned that splitting of IV candidate reults in bad code. I > could see only the positive end of this optimizations. > Could you please elaborate on the negative end of the fsplit-ivs-in-unroller > optimizations as you have mentioned that it results > In bad code in some cases. I had pointed to PR29256 in previous message. I also saw such examples in different benchmarks, and the situation is even worse on targets supporting auto-increment addressing mode.
Thanks, bin > > Thanks & Regards > Ajit > > Thanks, > bin >> optimization. Shouldn't be the fsplit-ivs-in-unroller optimization >> implemented in the unroller pass of rtl. I am looking at the implementation >> perspective for implementing the fsplit-ivs-in-unroller optimizations in the >> unroller rtl pass. >> >> Thanks & Regards >> Ajit >> >> Thanks, >> bin >>> >>> Ciao! >>> Steven
