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 PR68
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 should probably
>> happen earlier.
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 the
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 a
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 numbe
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 failu
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 for target arm-none-linuxgnu
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 look?
>
> Sorry for the break
On 11/09/2015 02:32 PM, Robert Suchanek wrote:
@@ -1707,6 +1749,8 @@ build_def_use (basic_block bb)
scan_rtx (insn, &XEXP (note, 0), ALL_REGS, mark_read,
OP_INOUT);
+ terminated_this_insn = NULL;
+
/* Step 4: Close chains for registers that
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 t
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
>> > with and without the patch w
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 entirel
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 numbe
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
wi
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 chain
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 insns
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 alloc
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
> 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
> effectiv
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
20 matches
Mail list logo
