Re: IRA undoing scheduling decisions

[Alex Turjan <aturjan at yahoo dot com>]

> 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.

I can imagine compiling other programs for which preserving the 4.3 allocation will induce performance degradation due to spilling. 

The register allocator tries to minimize the number of spills without taking into account the ILP implications (i.e., creating extra false dependencies). Perhaps one possible way to solve the problem would be to analyze why the register rename phase (which is responsible for spreading the registers) does not produces 2 registers.


--- On Wed, 8/26/09, Peter Bergner <bergner@vnet.ibm.com> wrote:

> From: Peter Bergner <bergner@vnet.ibm.com>
> Subject: Re: IRA undoing scheduling decisions
> To: "Charles J. Tabony" <tabonyee@austin.rr.com>
> Cc: gcc@gcc.gnu.org
> Date: Wednesday, August 26, 2009, 11:47 PM
> 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)
> 
> 
> 
>