This is the mail archive of the
mailing list for the GCC project.
Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
- From: Jeff Law <law at redhat dot com>
- To: Alex Velenko <Alex dot Velenko at arm dot com>, Shiva Chen <shiva0217 at gmail dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 29 Jul 2015 16:14:17 -0600
- Subject: Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression
- Authentication-results: sourceware.org; auth=none
- References: <CAH=PD7Z2s3Yw+nWkhKBzEVrvg=aeBLhL-rZJQ=VtpgOjZZ+DLA at mail dot gmail dot com> <55312EDF dot 90005 at redhat dot com> <CAH=PD7a0ofWfFBnJqD=6e5uYJY8v_GRjcvRuOBvy-x3EZNzFJg at mail dot gmail dot com> <5535DFB5 dot 3020003 at redhat dot com> <55B7C784 dot 4010104 at arm dot com>
On 07/28/2015 12:18 PM, Alex Velenko wrote:
It's not a regression, so backporting it would be generally frowned
upon. If you feel strongly about it, you should ask Jakub, Joseph or
Richi (the release managers) for an exception to the general policy.
On 21/04/15 06:27, Jeff Law wrote:
On 04/20/2015 01:09 AM, Shiva Chen wrote:
Thanks for your advice.
can_replace_by.patch is the new patch to handle both cases.
pr43920-2.c.244r.jump2.ori is the original jump2 rtl dump
pr43920-2.c.244r.jump2.patch_can_replace_by is the jump2 rtl dump
after patch can_replace_by.patch
Could you help me to review the patch?
Thanks. This looks pretty good.
I expanded the comment for the new function a bit and renamed the
function in an effort to clarify its purpose. From reviewing
can_replace_by, it seems it should have been handling this case, but
clearly wasn't due to implementation details.
I then bootstrapped and regression tested the patch on x86_64-linux-gnu
where it passed. I also instrumented that compiler to see how often
this code triggers. During a bootstrap it triggers a couple hundred
times (which is obviously a proxy for cross jumping improvements). So
it's triggering regularly on x86_64, which is good.
I also verified that this fixes BZ64916 for an arm-non-eabi toolchain
configured with --with-arch=armv7.
Installed on the trunk. No new testcase as it's covered by existing
I see this patch been committed in r222256 on trunk. Is it okay to port
this to fsf-5?