public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Peter Bergner <bergner@vnet.ibm.com>
To: "Charles J. Tabony" <tabonyee@austin.rr.com>
Cc: gcc@gcc.gnu.org
Subject: Re: IRA undoing scheduling decisions
Date: Thu, 27 Aug 2009 00:12:00 -0000	[thread overview]
Message-ID: <1251319659.5257.21.camel@otta> (raw)
In-Reply-To: <20090824235612.1UZ4O.12881.root@hrndva-web01-z01>

On Mon, 2009-08-24 at 23:56 +0000, Charles J. Tabony wrote:
> I am seeing a performance regression on the port I maintain, and I would appreciate some pointers.
> 
> When I compile the following code
> 
> void f(int *x, int *y){
>   *x = 7;
>   *y = 4;
> }
> 
> with GCC 4.3.2, I get the desired sequence of instructions.  I'll call it sequence A:
> 
> r0 = 7
> r1 = 4
> [x] = r0
> [y] = r1
> 
> When I compile the same code with GCC 4.4.0, I get a sequence that is lower performance for my target machine.  I'll call it sequence B:
> 
> r0 = 7
> [x] = r0
> r0 = 4
> [y] = r0

This is caused by update_equiv_regs() which IRA inherited from local-alloc.c.
Although with gcc 4.3 and earlier, you don't see the problem, it is still there,
because if you look at the 4.3 dumps, you will see that update_equiv_regs()
unordered them for us.  What is saving us is that sched2 reschedules them
again for us in the order we want.  With 4.4, IRA happens to reuse the same
register for both pseudos, so sched2 is hand tied and cannot schedule them
back again for us.

Looking at update_equiv_regs(), if I disable the replacement for regs
that are local to one basic block (patch below) like it existed before
John Wehle's patch way back in Oct 2000:

  http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00782.html

then we get the ordering we want.  Does anyone know why John removed
that part of the test in his patch?  Thoughts anyone?


Peter


Index: ira.c
===================================================================
--- ira.c	(revision 151111)
+++ ira.c	(working copy)
@@ -2510,6 +2510,7 @@ update_equiv_regs (void)
 		     calls.  */
 
 		  if (REG_N_REFS (regno) == 2
+		      && REG_BASIC_BLOCK (regno) < NUM_FIXED_BLOCKS
 		      && (rtx_equal_p (x, src)
 			  || ! equiv_init_varies_p (src))
 		      && NONJUMP_INSN_P (insn)



  parent reply	other threads:[~2009-08-26 20:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-25  9:47 Charles J. Tabony
2009-08-25 13:18 ` Adam Nemet
2009-08-26 10:09   ` Charles J. Tabony
2009-08-26 10:25     ` Adam Nemet
2009-08-25 15:41 ` Bingfeng Mei
2009-08-27  0:12 ` Peter Bergner [this message]
2009-08-27  0:58   ` Richard Guenther
2009-08-27  2:22     ` Peter Bergner
2009-09-01 20:34       ` Peter Bergner
2009-08-27 13:16   ` Alex Turjan
2009-08-29  3:47     ` Jeff Law
2009-09-01 14:38   ` Vladimir Makarov
2009-09-01 20:41     ` Peter Bergner
2009-09-01 20:45       ` Vladimir Makarov
2009-09-01 20:59         ` Peter Bergner
2009-09-02 15:49           ` Vladimir Makarov
2009-09-02 17:41             ` Peter Bergner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1251319659.5257.21.camel@otta \
    --to=bergner@vnet.ibm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=tabonyee@austin.rr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).