RE: [RFC][PATCH] Preferred rename register in regrename pass

Hi Christophe, > > > Hi, > I confirm that this fixes the build errors I was seeing. > Thanks. > Thanks for checking this. I'm still seeing a number of ICEs on the gcc-testresults mailing list across various ports but these are likely to be caused another patch. They are already reported as

RE: [RFC][PATCH] Preferred rename register in regrename pass

Hi, > I guess this is ok to stop the failures for now, but you may want to > move the check to the point where we set terminated_this_insn. Also, as > I pointed out earlier, clearing terminated_this_insn should probably > happen earlier. Here is the updated patch that I'm about to commit once

Re: [RFC][PATCH] Preferred rename register in regrename pass

On 11 November 2015 at 09:50, Robert Suchanek wrote: > Hi, > >> I guess this is ok to stop the failures for now, but you may want to >> move the check to the point where we set terminated_this_insn. Also, as >> I pointed out earlier, clearing terminated_this_insn

Re: [RFC][PATCH] Preferred rename register in regrename pass

On 10 November 2015 at 12:41, Robert Suchanek wrote: > Hi Christophe, > >> Hi, >> >> Since you committed this (r230087 if I'm correct), I can see that GCC >> fails to build >> ligfortran for target arm-none-linuxgnueabi --with-cpu=cortex-a9. > ... >> >> Can you have a

Re: [RFC][PATCH] Preferred rename register in regrename pass

On Tue, Nov 10, 2015 at 05:22:40PM +0100, Christophe Lyon wrote: > On 10 November 2015 at 12:41, Robert Suchanek > wrote: > > Hi Christophe, > > > >> Hi, > >> > >> Since you committed this (r230087 if I'm correct), I can see that GCC > >> fails to build > >> ligfortran

RE: [RFC][PATCH] Preferred rename register in regrename pass

Hi all, > > Now that 'make check' has had enough time to run, I can see several > > regressions in the configurations where GCC still builds. > > For more details: > > http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/230087/report-build-info.html > > > > This also causes

Re: [RFC][PATCH] Preferred rename register in regrename pass

On 11/10/2015 11:33 PM, Robert Suchanek wrote: The reason behind the failures is that the terminated_this_insn had a different number of consecutive registers (and mode) to the input operand in a move currently being considered for tying. In the fix, I allow tying only if there is matching

RE: [RFC][PATCH] Preferred rename register in regrename pass

Hi, > > Bernd, do you think that this check would be sufficient and safe? > > I'm not sure what would be better: check the mode, nregs plus perhaps > > consider tying only if nregs == 1. > > Hmm, but shouldn't the regno still be the same? Or is this a case where > we have a multi-word chain like

Re: [RFC][PATCH] Preferred rename register in regrename pass

On 11/09/2015 02:32 PM, Robert Suchanek wrote: @@ -1707,6 +1749,8 @@ build_def_use (basic_block bb) scan_rtx (insn, (note, 0), ALL_REGS, mark_read, OP_INOUT); + terminated_this_insn = NULL; + /* Step 4: Close chains for registers that die

Re: [RFC][PATCH] Preferred rename register in regrename pass

On 9 November 2015 at 18:01, Robert Suchanek wrote: > Hi, > >> On 11/09/2015 02:32 PM, Robert Suchanek wrote: >> > The results below were generated for CSiBE benchmark and the numbers in >> > columns express bytes in format 'net (gain/loss)' to show the difference >> >

RE: [RFC][PATCH] Preferred rename register in regrename pass

Hi Christophe, > Hi, > > Since you committed this (r230087 if I'm correct), I can see that GCC > fails to build > ligfortran for target arm-none-linuxgnueabi --with-cpu=cortex-a9. ... > > Can you have a look? Sorry for the breakage. I see that my assertion is being triggered. I'll investigate

RE: [RFC][PATCH] Preferred rename register in regrename pass

Hi Bernd, Sorry for late reply. The updated patch was bootstrapped on x86_64-unknown-linux-gnu and cross tested on mips-img-linux-gnu using r229786. The results below were generated for CSiBE benchmark and the numbers in columns express bytes in format 'net (gain/loss)' to show the difference

Re: [RFC][PATCH] Preferred rename register in regrename pass

On 11/09/2015 02:32 PM, Robert Suchanek wrote: The results below were generated for CSiBE benchmark and the numbers in columns express bytes in format 'net (gain/loss)' to show the difference with and without the patch when -frename-registers switch is used. I'm not entirely sure what the

RE: [RFC][PATCH] Preferred rename register in regrename pass

Hi, > On 11/09/2015 02:32 PM, Robert Suchanek wrote: > > The results below were generated for CSiBE benchmark and the numbers in > > columns express bytes in format 'net (gain/loss)' to show the difference > > with and without the patch when -frename-registers switch is used. > > I'm not

RE: [RFC][PATCH] Preferred rename register in regrename pass

Hi Bernd, Thanks for the comments, much appreciated. Comments inlined and a reworked patch attached. > On 09/17/2015 04:38 PM, Robert Suchanek wrote: > > We came across a situation for MIPS64 where moves for sign-extension were > > not converted into a nop because of IRA spilled some of the

RE: [RFC][PATCH] Preferred rename register in regrename pass

Hi Bernd, > Hi Robert, > > gcc/ > > * regrename.c (create_new_chain): Initialize terminated_dead, > > renamed and tied_chain. > > (find_best_rename_reg): Pick and check register from the tied chain. > > (regrename_do_replace): Mark head as renamed. > > (scan_rtx_reg): Tie

Re: [RFC][PATCH] Preferred rename register in regrename pass

Hi Robert, gcc/ * regrename.c (create_new_chain): Initialize terminated_dead, renamed and tied_chain. (find_best_rename_reg): Pick and check register from the tied chain. (regrename_do_replace): Mark head as renamed. (scan_rtx_reg): Tie chains in move

Re: [RFC][PATCH] Preferred rename register in regrename pass

On 09/17/2015 04:38 PM, Robert Suchanek wrote: We came across a situation for MIPS64 where moves for sign-extension were not converted into a nop because of IRA spilled some of the allocnos and assigned different hard register for the output operand in the move. LRA is not fixing this up as most

[RFC][PATCH] Preferred rename register in regrename pass

Hi, We came across a situation for MIPS64 where moves for sign-extension were not converted into a nop because of IRA spilled some of the allocnos and assigned different hard register for the output operand in the move. LRA is not fixing this up as most likely the move was not introduced by the

Re: [RFC][PATCH] Preferred rename register in regrename pass

On 09/17/2015 08:38 AM, Robert Suchanek wrote: Hi, We came across a situation for MIPS64 where moves for sign-extension were not converted into a nop because of IRA spilled some of the allocnos and assigned different hard register for the output operand in the move. LRA is not fixing this up as

Re: [RFC][PATCH] Preferred rename register in regrename pass

> I'll let Bernd comment on the patch itself. But I would say that if > you're setting up cases where we can tie the source/dest of an extension > together, then it's a good thing. It'll cause more of them to turn into > NOPs and it'll make the redundant extension elimination pass more >