This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH IRA] update_equiv_regs fails to set EQUIV reg-note for pseudo with more than one definition


On 03/02/15 08:29, Bin.Cheng wrote:
On Tue, Feb 3, 2015 at 3:24 PM, Jeff Law <law@redhat.com> wrote:
On 02/02/15 08:59, Alex Velenko wrote:

On 11/10/14 13:44, Felix Yang wrote:

Hello Jeff,

      I see that you have improved the RTL typesafety issue for ira.c,
so I rebased this patch
      on the latest trunk and change to use the new list walking
interface.
      Bootstrapped on x86_64-SUSE-Linux and make check regression tested.
      OK for trunk?

Hi Felix,
I believe your patch causes a regression for arm-none-eabi.
FAIL: gcc.target/arm/pr43920-2.c object-size text <= 54
FAIL: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2

This happens because your patch stops reuse of code for
" return -1;" statements in pr43920-2.c.

As far as I investigated, your patch prevents adding "(expr_list (-1)
(nil)" in ira pass, which prevents jump2 optimization from happening.

So before, in ira pass I could see:
"(insn 9 53 34 8 (set (reg:SI 110 [ D.4934 ])
          (const_int -1 [0xffffffffffffffff]))
/work/fsf-trunk-ref-2/src/gcc/gcc/testsuite/gcc.target/arm/pr43920-2.c:20
613
{*thumb2_movsi_vfp}
       (expr_list:REG_EQUAL (const_int -1 [0xffffffffffffffff])
          (nil)))"
But with your patch I get
"(insn 9 53 34 8 (set (reg:SI 110 [ D.5322 ])
          (const_int -1 [0xffffffffffffffff]))
/work/fsf-trunk-2/src/gcc/gcc/testsuite/gcc.target/arm/pr43920-2.c:20
615 {*thumb2_movsi_vfp}
       (nil))"

This causes a code generation regression and needs to be fixed.
Kind regards,

We'd need to see the full dumps.  In particular is reg110 set anywhere else?
If so then the change is doing precisely what it should be doing and the
test needs to be updated to handle the different code we generate.

Hmm, if I understand correctly, it's a code size regression, so I
don't think it's appropriate to adapt the test case.  Either the patch
or something else in GCC is doing wrong, right?

Hi Alex, could you please file a PR with full dump information for tracking?

Thanks,
bin
Hi Bin,
Created bugzilla ticket, as requested:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916
This test already existed in the testsuite, it is not new.
Kind regards,
Alex


Jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]